о одичес - ulstu.ruvenec.ulstu.ru/lib/disk/2014/Stepanov_2.pdf · 2014. 11. 26. · Рассмотрены концепции моделирования с помощью ПО

МИНИССТЕРСТВОО ТРАНСППОРТА РООССИЙСККОЙ ФЕДЕЕРАЦИИ

ФЕДЕРРАЛЬНОЕЕ ГОСУДААРСТВЕНННОЕ ОБРРАЗОВАТЕЕЛЬНОЕ УУЧРЕЖЕДДЕНИЕ

ВЫССШЕГО ППРОФЕСССИОНАЛЬЬНОГО ОББРАЗОВАННИЯ

УЛЬЯЯНОВСКООЕ ВЫСШШЕЕ АВИААЦИОННООЕ УЧИЛЛИЩЕ

ГРАЖДДАНСКОЙЙ АВИАЦИИИ (ИНСТТИТУТ)

СТЕПАННОВ С.ММ.

МЕХОННОШИН ВВ.С.

СТЕПАННОВ Д.С..

МЕТ

МОДЕ

ИС

ТОДАМ

ЕЛИРОВ

О

ССЛЕДО

И ФУНК

ВАНИЯ

ОБЕСПЕ

Учебн

ОВАНИЕ

КЦИОН

С ИСПО

ЕЧЕНИЯ

но-мет

Уль

Е СИСТЕ

НАЛЬНО

ОЛЬЗОВ

Я «BPwi

тодичес

ьяновск 2

ЕМ УПР

ОГО И И

РАВЛЕН

ВАНИЕМ

in 4.1» И

ское по

2006

ИМИТАЦ

НИЯ

М ПРОГ

ЦИОННО

И «Arena»

собие

ГРАММН

ОГО

НОГО

»

ББК З 973.26-018.2 я7 + З 965.7 я7

С 79

Степанов С.М. Исследование систем управления методами функционально-

го и имитационного моделирования с использованием программного обеспече-

ния «BPwin 4.1» и «Arena»: Учеб.-метод. пособие / С.М. Степанов, В.С. Мехо-

ношин, Д.С. Степанов. – Ульяновск: УВАУ ГА, 2006. – 81 с.

Рассмотрены концепции моделирования с помощью ПО «BPwin 4.1» и

«Arena», правила и методы создания функциональных и имитационных моде-

лей для наглядного представления системы на любом уровне детализации.

Приведены задания к практическим занятиям по исследованию систем

управления (на примере образовательного процесса), а также рекомендации по

их применению.

Предназначено для курсантов и студентов заочной формы обучения специа-

лизации 061140 – Менеджмент на воздушном транспорте.

Печатается по решению Редсовета училища.

© Ульяновск, УВАУ ГА, 2006.

С.М. Степанов, В.С. Мехоношин, Д.С. Степанов

ИСУ методами функ-го и имит-го моделирования с исп-ем программного обеспечения «BPwin 4.1» и «Arena»: УМП

2 © НИЛ НОТ НИО УВАУ ГА (и), 2010

СОДЕРЖАНИЕ

Введение………………………………………………………………………….4

Часть I. Использование ПО «BPwin» для функционального

моделирования процессов управления современным вузом…..6

Основные положения…………………………………………………………6

Глоссарий……………………………………………………………………...8

1. Концепция IDEF0……………………………………………………….....12

2. Диаграммы IDEF0…………………………………………………………16

3. Методика разработки функциональных моделей в среде IDEF0………30

Контрольные вопросы……………………………….……………………....35

Часть II. Использование ПО «Arena» для имитационного

моделирования процессов управления современным вузом…36

Основные положения…………………………………………………….......36

1. Концепции моделирования……………………………………………….38

2. Краткий обзор среды разработки модели «Arena»……………………...41

3. Создание модели………………………………………………………......64

Контрольные вопросы……………………………………………………….67

Часть III. Рекомендации по проведению практических занятий

с использованием программных комплексов

«BPwin» и «Arena»………………………………………………..68

Библиографический список……………………………………………………72

Приложения……………………………………………………………………..73




ВВЕДЕНИЕ

Образовательный процесс представляет собой довольно сложное структур-

ное объединение различных подсистем и может рассматриваться как систем-

ный объект. В подсистему теоретического обучения входят: учебный материал,

учебные пособия, различные технические и аудиовизуальные средства; объект

обучения – ученик, который также может рассматриваться в качестве сложной

самоорганизующейся подсистемы; направляющий и руководящий центр всей

системы – преподаватель.

В силу этого рассмотрение всего комплекса вопросов, связанных со струк-

турно-системной оптимизацией, необходимо проводить с системных позиций.

Учебный процесс в вузе – явление сложное, зависящее от большого числа

взаимосвязанных факторов, причем изменение любого из них приводит к изме-

нению других. Если рассматривать учебный процесс как технологию переме-

щения курсантов с курса на курс на основании результатов усвоения ими опре-

деленного объема знаний, установленного основной образовательной програм-

мой, то можно выделить ряд внутренних и внешних по отношению к вузу фак-

торов, определяющих динамику этого перемещения. Например, к внешним

факторам можно отнести уровень школьной подготовки абитуриентов, проход-

ной балл в вуз, величину конкурса; к внутренним факторам можно отнести ор-

ганизацию и контроль учебной работы курсантов, критерии оценки знаний кур-

сантов, качество планирования учебных занятий, уровень преподавания и каче-

ственный состав преподавателей и т.д.

В процессе выполнения практических заданий курсант (студент) должен:

знать:

– конкретные методы исследования, наиболее эффективные для изуче-

ния систем управления;




– принципы функционального моделирования;

– принципы имитационного моделирования;

уметь:

– планировать и организовывать исследования, оценивать и использовать

их результаты;

– проводить анализ процессов;

– на основе проведенного анализа строить функциональные и имитаци-

онные модели;

– проводить структурную оптимизацию процессов;

приобрести:

– навыки разработки и оптимизации процессов;

– навыки разработки практических и конкретных рекомендаций по со-

вершенствованию систем управления.




ЧАСТЬ I

ИСПОЛЬЗОВАНИЕ ПО «BPWIN»

ДЛЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ

ПРОЦЕССОВ УПРАВЛЕНИЯ СОВРЕМЕННЫМ ВУЗОМ

Основные положения

BPwin является мощным инструментом для создания моделей, позволяю-

щих анализировать, документировать и планировать изменения сложных про-

цессов. BPwin предлагает средства для сбора всей необходимой информации о

работе предприятия и графического изображения этой информации в виде це-

лостной и непротиворечивой модели. Причем, поскольку модель является неко-

торым графическим представлением действительности, можно утверждать, что

человек вернулся к своему излюбленному средству документирования процес-

сов – к рисунку. Но возвращение это произошло на новом уровне: целостность

и непротиворечивость модели-рисунка (качества, о которых раньше не было и

речи) гарантируются рядом методологий и нотаций, которым следуют создате-

ли модели. BPwin поддерживает три таких методологии: IDEF0, IDEF3 и DFD –

позволяющие анализировать процесс с трех ключевых точек зрения:

– с точки зрения функциональности системы. В рамках методологии

IDEF0 (Integration Definition for Function Modeling) процесс представляется в ви-

де набора элементов-работ, которые взаимодействуют между собой, а также по-

казываются информационные, людские и производственные ресурсы, потреб-

ляемые каждой работой;




– с точки зрения последовательности выполняемых работ. Еще более

точную картину можно получить, дополнив модель диаграммами IDEF3. Этот

метод привлекает внимание к очередности выполнения событий. В IDEF3

включены элементы логики, что позволяет моделировать и анализировать аль-

тернативные сценарии развития процесса;

– с точки зрения потоков информации (документооборота) в системе.

Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отраже-

но в модели IDEF3, поскольку они описывают потоки данных, позволяя про-

следить, каким образом происходит обмен информацией между функциями

внутри системы. В то же время диаграммы DFD оставляют без внимания взаи-

модействие между функциями.

BPwin позволяет проверять создаваемые модели с точки зрения синтаксиса

выбранной методологии, проверять ссылочную целостность между диаграмма-

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

модель, а не просто рисунок. При этом сохраняются главные преимущества ри-

сунка – простота создания и наглядность.

Основной из трех методологий, поддерживаемых BPwin, является IDEF0.

IDEF0 относится к семейству IDEF, которое появилось в конце шестидесятых

годов под названием SADT (Structured Analysis and Design Technique). IDEF0

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

вых систем применение IDEF0 имеет своей целью определение требований и

указание функций для последующей разработки системы, отвечающей постав-

ленным требованиям и реализующей выделенные функции. Применительно к

уже существующим системам IDEF0 может быть использована для анализа

функций, выполняемых системой, и отображения механизмов, посредством ко-

торых эти функции выполняются. Результатом применения IDEF0 к некоторой

системе является модель этой системы, состоящая из иерархически упорядо-

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

другом с помощью перекрестных ссылок.




Часть I

Глоссарий

Под глоссарием понимается список определений для ключевых слов, слово-сочетаний и аббревиатур, связанных с узлами, блоками, стрелками или с моде-лью IDEF0 в целом.

В методологии IDEF0 применяют следующие термины: Блок: прямоугольник, содержащий имя и номер и используемый для описа-

ния функции. Ветвление: разделение стрелки на два или большее число сегментов. Может

означать «развязывание пучка». Внутренняя стрелка: входная, управляющая или выходная стрелка, концы

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

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

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

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

Декомпозиция: разделение моделируемой функции на функции-компоненты. Диаграмма: часть модели, описывающая декомпозицию блока. Диаграмма А – 0 (А минус ноль): специальный вид контекстной диаграм-

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

Диаграмма-иллюстрация (FEO): графическое описание, используемое для сообщения специфических фактов о диаграмме IDEF0. При построении диа-грамм FEO можно не придерживаться правил IDEF0.




Часть I

Дочерний блок: блок на дочерней (порожденной) диаграмме. Дочерняя диаграмма: диаграмма, детализирующая родительский (порож-

дающий) блок. Древо узлов: представление отношений между родительскими и дочерними

узлами модели IDEF0 в форме древовидного графа. Имеет то же значение и со-держание, что и перечень узлов.

Имя блока: глагол или глагольный оборот, помещенный внутри блока и описывающий моделируемую функцию.

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

Код ICOM (аббревиатура: Input – вход, Control – управление, Output – выход, Mechanism – механизм): код, обеспечивающий соответствие граничных стрелок дочерней диаграммы стрелкам родительского блока; используется для ссылок.

Контекст: окружающая среда, в которой действует функция (или комплект функций) на диаграмме.

Контекстная диаграмма: диаграмма, имеющая узловой номер А – n (А ми-нус n) (n ≥ 0) и представляющая контекст модели. Диаграмма А – 0 является необходимой (обязательной) контекстной диаграммой, диаграммы с узловыми номерами А – 1, А – 2, ..., А – n – дополнительные контекстные диаграммы.

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

Модель: искусственный объект, представляющий собой отображение (об-раз) системы и ее компонентов.

Модель IDEF0: графическое описание системы, разработанное с определен-ной целью и с выбранной точки зрения.

Номер блока: число (от 0 до 6), помещаемое в правом нижнем углу блока и однозначно идентифицирующее блок на диаграмме.

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




Часть I

Примечание к модели: текстовый комментарий, являющийся частью диа-

граммы IDEF0 и используемый для записи факта, не нашедшего графического

изображения.

Родительская диаграмма: диаграмма, которая содержит родительский блок.

Родительский блок: блок, который подробно описывается дочерней диа-

граммой.

С-номер: номер, создаваемый в хронологическом порядке и используемый

для идентификации диаграммы и прослеживания ее истории; может быть ис-

пользован в качестве ссылочного выражения при определении конкретной вер-

сии диаграммы. Обычно С-номер состоит из инициалов автора модели и хроно-

логических данных (даты создания очередной версии диаграммы).

Связывание/развязывание: объединение значений стрелок в составное

значение (связывание в «пучок») или разделение значений стрелок (развязыва-

ние «пучка»), выраженное синтаксисом слияния или ветвления стрелок.

Сегмент стрелки: сегмент линии, который начинается или заканчивается на

стороне блока, в точке ветвления / слияния или на границе (несвязанный конец

стрелки).

Семантика графического языка: значение синтаксических компонентов

языка IDEF0.

Синтаксис графического языка: структурные компоненты или характери-

стики языка IDEF0 и правила, которые определяют отношения между ними.

Система: совокупность взаимосвязанных и взаимодействующих частей,

выполняющих некоторую работу.

Слияние: объединение двух или большего числа сегментов стрелок в один

сегмент. Может означать «связывание пучка».

Стрелка: направленная линия из одного или нескольких сегментов, которая

моделирует открытый канал или канал, передающий данные или материальные

объекты от источника (начальная точка стрелки) к потребителю (конечная точка).

Имеется четыре класса стрелок: входная, выходная, управляющая и стрелка ме-

ханизма (включает в себя стрелку вызова).




Часть I

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

Стрелка механизма: класс стрелок, которые отображают механизмы IDEF0, то есть средства, используемые для выполнения функции; включает специальный случай стрелки вызова. Стрелки механизмов связываются с ниж-ней стороной блока IDEF0.

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

Текст: любой текстовый (не графический) комментарий к графической диа-грамме IDEF0.

Тильда: небольшая ломаная линия, используемая для соединения метки с конкретным сегментом стрелки или примечания модели с компонентом диа-граммы.

Точка зрения: указание на должностное лицо или подразделение организа-ции, с позиции которого разрабатывается модель. Для каждой модели точка зрения единственная.

Узел: блок, порождающий дочерние блоки; родительский блок. Узловая ссылка: код, присвоенный диаграмме для ее идентификации и оп-

ределения положения в иерархии модели; формируется из сокращенного имени модели и узлового номера диаграммы с дополнительными расширениями.

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

Узловой номер диаграммы: часть узловой ссылки диаграммы, которая со-ответствует номеру родительского блока.

Управляющая стрелка: класс стрелок, отображающих управления, то есть

условия, при выполнении которых выход блока будет правильным. Данные или




Часть I

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

создающей соответствующий выход. Управляющие стрелки связываются с

верхней стороной блока IDEF0.

Функция: деятельность, процесс или преобразование, моделируемые бло-ком IDEF0, идентифицируемые глаголом или глагольной формой, которая опи-сывает, что должно быть выполнено.

Цель: краткая формулировка причины создания модели.

1. Концепция IDEF0

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

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

Итеративное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разра-ботчик предлагает вариант модели, который подвергают обсуждению, рецен-зированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.




Часть I

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

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

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

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




Часть I

ее эксплуатации не возникало вопросов, связанных с неполнотой или некор-ректностью документации. Программный продукт Design/IDEF 3.7 (и более поздние версии) фирмы Meta Software Corporation поддерживает автоматиче-ское соблюдение большинства из перечисленных правил.

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

– диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые;

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

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

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

1.1. Синтаксис графического языка IDEF0

Блоки. Для блоков установлены следующие синтаксические правила: – размеры блоков должны быть достаточными для того, чтобы включить

имя и номер блока; – блоки должны быть прямоугольными; – блоки должны быть нарисованы сплошными линиями.

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

Для стрелок установлены следующие синтаксические правила: – стрелки могут быть прямыми или ломаными (прил. 1);




Часть I

– ломаные стрелки изменяют направление только под углом 90°, отрезки стрелок соединяются дугами;

– стрелки должны быть нарисованы сплошными линиями. Можно ис-пользовать линии различной толщины и цвета;

– стрелки должны присоединяться к блоку на его сторонах. Присоедине-ние в углах не допускается;

– концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать ее.

1.2. Семантика графического языка IDEF0

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

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

Сводка семантических правил для блоков и стрелок

1. Имя блока должно быть глаголом или глагольным оборотом. Например, имя блока «Выполнить проверку» означает, что блок с таким именем превра-щает непроверенные детали в проверенные.

2. Сторона функционального блока, к которой присоединена стрелка, одно-значно определяет ее роль:

– входные стрелки должны связываться с левой стороной блока; – управляющие стрелки должны связываться с верхней стороной блока; – выходные стрелки должны связываться с правой стороной блока;

– стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока;

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




Часть I

Стандартное расположение стрелок показано на рис. 1.

Рис. 1

3. Сегменты стрелок, за исключением стрелок вызова, должны помечаться

существительным или оборотом существительного, если только единственная

метка стрелки не относится к стрелке в целом. Метки сегментов позволяют

конкретизировать данные или материальные объекты, передаваемые этими

сегментами, с соблюдением синтаксиса ветвлений и слияний.

4. Чтобы связать стрелку с меткой, следует использовать тильду.

2. Диаграммы IDEF0

IDEF0-модели состоят из документов трех типов: графических диаграмм,

текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга.

Графическая диаграмма – главный компонент IDEF0-модели, содержащий бло-

ки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения.

Блоки представляют основные функции моделируемого объекта. Эти функции

могут быть разбиты (декомпозированы) на составные части и представлены в

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

пор, пока объект не будет описан на уровне детализации, необходимом для дос-

тижения целей конкретного проекта.

Диаграмма верхнего уровня обеспечивает наиболее общее описание объекта

моделирования, за ней следует серия дочерних диаграмм, дающих более де-

тальное представление об объекте.

ИМЯ

БЛОКА

Управление

Вход Выход

Механизм Вызов




Часть I

2.1. Контекстная диаграмма верхнего уровня

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на

которой объект моделирования представлен единственным блоком с гранич-

ными стрелками (см. прил. 1, рис. 1). Эта диаграмма называется А – 0 (А минус

ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с

окружающей средой. Поскольку единственный блок представляет весь объект,

его имя – общее для всего проекта. Это же справедливо и для всех стрелок диа-

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

объекта. Диаграмма А – 0 устанавливает область моделирования и ее границу.

Контекстная диаграмма А – 0 также должна содержать краткие утвержде-

ния, определяющие точку зрения должностного лица или подразделения, с по-

зиций которого создается модель, и цель, для достижения которой ее разраба-

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

этот процесс в определенные рамки. Точка зрения определяет, что и в каком

разрезе можно увидеть в пределах контекста модели. Изменение точки зрения

приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной

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

зрения на тот же самый объект.

Формулировка цели выражает причину создания модели, то есть содержит

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

мере определяет ее структуру. Наиболее важные свойства объекта обычно вы-

являются на верхних уровнях иерархии; по мере декомпозиции функции верх-

него уровня эти свойства уточняются.

2.2. Дочерняя диаграмма

Единственная функция, представленная на контекстной диаграмме верхнего

уровня, может быть разложена на основные подфункции посредством создания

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

элементы следующего, более низкого уровня, и так происходит до тех пор, пока




Часть I

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

сформулированные в цели моделирования. Подфункция моделируется отдель-

ным блоком. Каждый родительский блок подробно описывается дочерней диа-

граммой на более низком уровне (рис. 2). Все дочерние диаграммы должны

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

Рис. 2




Часть I

2.3. Родиттельскаяя диаграммма

Родит

блоков. И

декомпоз

диаграмм

подробно

может бы

(см. прил

но описы

ней диагр

ским бло

тельская д

Иными сл

зируемая

ма являетс

о описыв

ыть как р

л. 1, рис. 2

ываться до

рамме). О

оком и доч

диаграмма

ловами, эт

функция

ся также д

ает некот

родительс

2, 3, 4). Ан

очерней д

Основное и

черней диа

а – та, ко

то диаграм

со всеми

дочерней

торый род

ской (сод

налогично

диаграммо

иерархиче

аграммой

оторая сод

мма верхн

и ее связям

диаграмм

дительски

ержать ро

о, блок мо

ой), так и

еское отн

й, которая

держит од

него уровн

ми. Кажд

мой, поско

ий блок.

одительск

ожет быть

дочерним

ношение с

его подро

дин или б

ня, на кото

ая обычн

ольку, по

Таким об

кие блоки

ь как роди

м (появля

уществуе

обно описы

более роди

орой расп

ая (некон

определе

бразом, д

и), так и

ительским

яющимся

ет между р

ывает (см

ительских

полагается

нтекстная)

ению, она

диаграмма

дочерней

м (подроб-

на дочер-

родитель-

м. рис. 2).

х

я

)

а

а

й

-

-

-

То, чт

ка на ди

ным кодо

может ф

ключаетс

содержит

казанные

блока ди

диаграмм

то блок яв

иаграмме

ом, напис

формирова

ся в том, ч

т цифры,

е на рис.

иаграммы

мы А0; по

вляется д

предшест

санным п

аться нес

что код, н

определя

3 коды о

, которая

оследняя ц

очерним

твующего

од правы

сколькими

начинающ

яемые но

значают,

я, в свою

цифра код

и раскрыв

о уровня,

ым нижним

и способа

щийся с бу

мерами р

что диагр

очередь,

да – номе

вает соде

, указыва

м углом б

ами, из к

уквы А (п

родительс

рамма яв

является

ер блока д

ржание р

ется спец

блока. Эт

которых с

по имени

ских блок

ляется де

декомпо

диаграммы

родительск

циальным

тот ссылоч

самый про

диаграмм

ков. Напри

екомпозиц

зицией 6-

ы А61.

кого бло-

м ссылоч-

чный код

остой за-

мы А – 0),

имер, по-

цией 1-го

-го блока

-

-

д

-

,

-

о

а

Рис. 3




Часть I

2.4. Отношшения ммежду блоками диаграмммы и друггими диааграммаами (окружающеей средойй)

В метпределах

тодологиих одной д

и IDEF0 сиаграммы

существуы:

ует шесть типов оттношенийй между бблоками вв

а) доминиррование; б)) управленние;

вход; в) выход – г) обратнаяя связь поо управленнию; д)) обратнаяя связь поо входу; е) выход – механизмм.

Первоем блокограмме ввее. Домдругие б

ое из перов на диавыше и леминированблоки диаг

ечисленнаграмме. евее, домние понимграммы.

ных отношПредпол

минируютмается ка

шений опрлагается, чт над блокак влияни

ределяетсчто блокками, расие, которо

ся взаимни, располположенное один б

ным расположенныеными нижблок оказ

оложени-е на диа-же и пра-зывает на

---а

Остался соотве

льные пятетствующ

ть отношещими стре

ений опиелками.

сывают ссвязи межжду блоками и изоббражают--

Отноотражаю

шения упют прямые

правлениее взаимод

е и выходдействия,

д – входкоторые

являютсяпонятны

я простейи очевид

йшими, пдны.

посколькуу

Отножит упра

Отного блока

ошение упавляющимошение выс входом

правлениям воздейс

я (рис. 4, ствием на

а) возника блок с м

ыход – вхом другого

од (рис. 4блока с м

4, б) вознименьшим

Рис. 4

кает, когдменьшим д

да выход доминиро

одного блованием.

лока слу-

-

икает придоминир

и соединерованием.

ении выхо

ода одно-

-




Часть I

Отноются болцию (вышим дом

Обраблока соз

Обравится вхо

Отноход одно«выход –ния и рания фунинструмепростран

шения облее сложныход функминировантная связздает упртная свяодом дру

ошение выой функц– механизаспределенкций сисентов и онства, фин

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

ыход – меции становзм» возниения ресурстемы (наоборудовнансиров

связи по упами отнояет на буо впоследсавлению (е воздейсоду (рис. ка с больш

еханизм (вится среикают пррсов, создапример ания, обуание, заку

управлениошений, пудущее выствии вли(рис. 5, а)ствие на б5, б) имешим доми

Рис. 5

(рис. 6) отедством ди отображдания илиприобретучение пеупка мате

Рис. 6

ию и обрапосколькуыполнениияет на ис) возникаеблок с болет место,инировани

тражает сдостиженижении в ми подгототение илиерсонала,ериалов и

атной свяу они преие другихсходную ф

язи по вхоедставляюх функцийфункцию

оду явля-ют итера-й с боль-ю).

---

ет, когда льшим дом

выход неминирова

екоторогоанием.

о

, когда выием.

ыход блокка стано--

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

ю, при котдля другопроцедур дств для ввление трация физ

торой вы-ой. Связипополне-выполне-ребуемыхзического

-и --х о




Часть I

Все о

есть таки

другими

грамме о

ми (рис.

описанны

ими, у ко

диаграм

окружающ

7).

ые выше о

оторых об

ммами, яв

щей средо

отношени

ба конца с

вляющими

ой (окруж

ия отображ

связаны с

ися по от

жением),

жаются в

с блоками

тношению

описываю

внутренни

и диаграм

ю к рассм

ются гран

ими стрел

ммы. Отно

матривае

ничными

лками, то

ошения с

мой диа-

стрелка-

о

с

-

-

2.

Ветвл

графичес

Чтобы

источник

связываю

возникаю

–

метке стр

сегменто

–

объекты,

ваемую м

5. Ветвл

ление и с

скими эле

ы стрелки

ками и б

ются с се

ют опреде

непомече

релки пер

ов);

сегменты

, указанн

меткой ка

ление и с

лияние ст

ементами

и и их се

блоками-п

егментам

еленные о

енные сег

ред ветвл

ы, помече

ные в мет

аждого ко

Рис. 7

слияние сегментов стреллок

трелок пр

и (линиям

ризвано у

ми).

уменьшитть загруженность ддиаграммм

егменты п

потребите

и посред

отношени

гменты (р

лением (т

енные по

тке стрел

онкретног

правильно

елями, ис

дством ти

ия, описан

о описыв

спользует

ильд. При

нные ниж

али связи

тся аппар

и этом м

же:

и между

рат меток

между сег

блоками-

к. Метки

гментами

-

и

и

рис. 8) со

о есть все

одержат в

е объекты

все объек

ы принадл

кты, указ

лежат каж

анные в

ждому из

в

з

осле точки

ки перед

го сегмен

и ветвлен

д ветвлени

нта;

ния (рис.

ием, или

9), соде

их часть

ержат все

ь, описы-

е

-




Часть I

–

стрелки

занные в

при слиян

содержит

в общей м

нии непо

т все объ

метке стре

омеченных

ъекты, пр

елки посл

х сегмент

ринадлеж

ле слияния

тов (рис.

ащие сли

я;

10) объед

иваемым

диненный

сегмента

й сегмент

ам и ука-

т

-

–

содержи

перечисл

отсутств

жащие сл

при слия

т все или

ленные в

вует, это о

ливаемым

янии пом

и некотор

общей м

означает,

м сегмент

меченных

ые объек

етке посл

что общ

там.

сегменто

кты, прин

ле слияни

ий сегмен

ов (рис. 1

адлежащи

ия. Если о

нт переда

11) объед

ие сливае

общая мет

ает все об

диненный

емым сегм

тка после

бъекты, п

й сегмент

ментам и

е слияния

принадле-

Рис. 8

Рис. 9

т

и

я

-




Часть I

2.

На об

входы, у

Источни

чая роди

(за искл

стрелкам

6. Грани

бычной (

управлени

ик или пот

ительскую

лючением

м родител

ичные ст

(неконтек

ия, выход

требителя

ю диаграм

м стрелок

льского бл

трелки

кстной) д

ды или м

я граничн

мму. Все

к, помеще

лока (рис

Рис. 10

Рис. 11

диаграмме

механизмы

ных стрел

граничны

енных в

. 12).

е граничн

ы родител

лок можн

ые стрелк

туннель)

ные стрел

льского б

но обнару

ки на доч

) должны

лки пред

блока диа

ужить, тол

черней ди

ы соответ

ставляют

аграммы.

лько изу-

иаграмме

тствовать

т

.

-

е

ь




Часть I

ICOM

ные стре

ция, назв

или М, п

диаграмм

Выход (

следует

стрелки к

сверху в

грамме у

ляющей

M-кодиро

елки на д

ванная IC

приведенн

ме, идент

Output) и

число, о

к родител

вниз). Нап

указывает

стрелке р

ование г

дочерней

COM-код

ные около

тифициру

или Меха

пределяю

льскому б

пример, к

т, что эта

родительс

раничны

диаграмм

ом, опред

о несвяза

уют стрел

анизм (M

ющее отн

блоку (это

код «С3»

а стрелка

ского бло

Рис. 12

ых стрело

ме со стр

деляет зн

анного кон

лку как В

echanism)

носительн

о положен

возле гр

соответст

ока.

ок. ICOM

елками р

начения с

нца грани

Вход (Inp

) в родит

ное полож

ние опред

раничной

твует тре

M-коды св

одительс

соединени

ичной стр

put), Упра

тельском

жение точ

деляется с

стрелки

етьей (счи

вязывают

кого блок

ий. Буквы

релки на д

авление (

блоке. З

чки подк

слева нап

на дочер

итая слев

т гранич-

ка. Нота-

ы I, С, О

дочерней

(Control),

За буквой

ключения

право или

рней диа-

а) управ-

-

-

О

й

,

й

я

и

-

-




Часть I

ICOM

тельским

шей деко

щего уро

связываю

блоков.

M-кодиров

м блоком

омпозици

овня, то н

ющие гра

вание свя

. Если бл

ии и подр

на каждую

аничные с

язывает к

локи на д

робно опи

ю новую

стрелки эт

аждую до

дочерней

исываютс

диаграмм

тих диагр

очернюю

диаграм

ся на доче

му назнач

рамм со с

диаграмм

мме подве

ерних диа

чаются но

стрелками

му со сво

ергаются

аграммах

овые ICO

и их роди

оим роди-

дальней-

х следую-

OM-коды,

ительских

-

-

-

,

х

Иногд

гут меня

пример,

черней д

управлен

да буквен

яться при

управляю

диаграмме

нием для

нные ICO

переходе

ющая стре

е (рис. 13

одного ил

OM-коды,

е от роди

елка в род

). Аналог

ли нескол

определя

ительског

дительско

гично, вхо

льких доч

яющие ро

го блока к

ом блоке

од родите

черних бл

оли грани

к дочерне

может бы

ельского

локов.

чных стр

ей диагра

ыть входо

блока мо

елок, мо-

амме. На-

ом на до-

жет быть

-

-

-

ь

2.

При п

1. В

которая

ной диаг

7. Прави

построени

В составе

содержит

грамме А

ила пост

ии диагра

е модели

т только

– 0 долж

Рис. 13

троения ддиаграммм

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

должна п

один бло

ен быть 0

присутств

ок. Номер

0.

овать кон

р единств

нтекстная

венного б

я диаграмм

блока на к

ма А – 0,

контекст-

,

-




Часть I

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

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

4. Каждый блок неконтекстной диаграммы получает номер, помещае-мый в правом нижнем углу; порядок нумерации – от верхнего левого к ниж-нему правому блоку (от 1 до 6). Если некоторые блоки на диаграмме разме-щены не по диагонали, то сначала нумеруются «диагональные» блоки (начи-ная с левого верхнего блока), а затем – «недиагональные» блоки, начиная с нижнего правого против часовой стрелки. Система нумерации необходима для однозначной идентификации блоков в пределах диаграммы и для генера-ции узловых номеров.

5. Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на дочернюю диаграмму; ссылка (например узловой номер, С-номер или номер страницы) помещается под правым нижним углом блока.

6. Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отобра-жают тождественные данные.

7. При наличии стрелок со сложной топологией целесообразно повторить

метку для удобства ее идентификации.




Часть I

8. Следует обеспечить максимальное расстояние между блоками и пово-

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

ния чтения диаграммы. Одновременно уменьшается вероятность того, что две

разные стрелки будут перепутаны.

9. Блоки всегда должны иметь хотя бы одну управляющую и одну вход-

ную стрелку, но могут не иметь выходных стрелок.

10. Если одни и те же данные служат и для управления, и для входа, изо-

бражается только стрелка управления. Этим подчеркивается управляющий ха-

рактер данных и уменьшается сложность диаграммы.

11. Максимально увеличенное расстояние между параллельными стрелками

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

12. Стрелки связываются (сливаются), если они представляют сходные

данные и их источник не указан на диаграмме.

13. Обратные связи по входу должны быть показаны как «вниз и под».

Так же показываются обратные связи посредством механизма. Таким образом,

обеспечивается показ обратной связи при минимальном числе линий и пересе-

чений.

14. Циклические обратные связи для одного и того же блока изображают-

ся только для того, чтобы их выделить. Обычно обратную связь изображают на

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

но используемые объекты.

15. Стрелки объединяются, если они имеют общий источник или прием-

ник либо представляют связанные данные. Общее название лучше описывает

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

роны блока, если, конечно, природа данных не слишком разнородна.

16. Если возможно, стрелки присоединяются к блокам в одной и той же

позиции. Тогда соединение стрелок конкретного типа с блоками будет согласо-

ванным и чтение диаграммы упростится.

17. При соединении большого числа блоков необходимо избегать необя-

зательных пересечений стрелок. Следует минимизировать число петель и пово-

ротов каждой стрелки.




Часть I

18. Блоки (функции) дочерней диаграммы являются сопряженными через

среду (диаграмму или родительский блок), если они имеют связи с источником,

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

данных относятся к какому-либо блоку.

2.8. Ссылочные выражения (коды)

Ссылочные выражения (коды) присваиваются всем элементам модели: диа-

граммам, блокам, стрелкам и примечаниям. Ссылочные выражения затем могут

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

мент модели.

Основное ссылочное выражение – узловой номер, который появляется там,

где выполняется декомпозиция функционального блока и создается его под-

робное описание на дочерней диаграмме. Все остальные ссылочные коды бази-

руются на узловых номерах.

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

узловой номер формируется добавлением номера блока к номеру диаграммы,

на которой он появляется. Например, А252 – это узловой номер блока 2 на диа-

грамме А25. Все узловые номера IDEF0 начинаются с заглавной буквы, напри-

мер «А». Когда родительский блок подробно описывается дочерней диаграм-

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

Контекстные диаграммы и дочерняя диаграмма верхнего уровня – исключе-

ния в вышеуказанной схеме узловой нумерации. Каждая модель IDEF0 имеет

контекстную диаграмму верхнего уровня – диаграмму А – 0. Эта диаграмма со-

держит единственный «высший» блок, который является уникальным родите-

лем всей модели и несет уникальный номер 0 (нуль) и узловой номер А0. Каж-

дая модель IDEF0 должна также иметь, по крайней мере, одну дочернюю диа-

грамму, содержащую декомпозицию блока А0 на 3... 6 дочерних блоков. Этим

блокам присваиваются уникальные узловые номера А1, А2, ... , А6. Таким обра-

зом, последовательность [А0, Al, ... , An] начинает нумерацию узлов для любой

модели.




Часть I

Например, модель может иметь следующие узловые номера:

А –1 Дополнительная контекстная диаграмма

А – 0 Обязательная контекстная диаграмма верхнего уровня (со-

держащая высший блок А0)

А0 Верхняя дочерняя диаграмма

А1, А2, ... , А6 Дочерние диаграммы

Узловой номер используется также для обозначения того, что блок подверг-

нут декомпозиции. В этом случае узловой номер, совпадающий с номером до-

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

ской диаграмме.

Перечень узлов представляет информацию о входящих в модель узлах в

форме списка, напоминающего обычное оглавление и отражающего иерархиче-

скую структуру модели. Например:

А0 Организовать образовательный процесс

А1 Набор студентов

А2 Организовать учебный процесс

А21 Организовать теоретическое обучение курсантов 1-го курса

А22 Организовать теоретическое обучение, самостоятельную работу и

аттестацию курсантов 1-го курса в первом семестре

3. Методика разработки функциональных моделей

в среде IDEF0

В предыдущих разделах описаны инструментальные возможности методо-

логии IDEF0 как средства функционального моделирования производственно-

технических и организационно-экономических систем. В настоящем разделе

кратко излагаются некоторые методические приемы построения моделей, об-

легчающие практическое применение этой методологии.




Часть I

3.1. Общие положения

Функциональный блок, отображающий моделируемую систему в целом

(блок А0), и блоки на любом уровне декомпозиции являются преобразующими

блоками.

Преобразующий блок – блок IDEF0-диаграммы, преобразующий входы в

выходы под действием управлений при помощи механизмов.

Преобразование – цель и результат работы любого блока на диаграмме лю-

бого уровня декомпозиции. Преобразованию в блоке могут подвергаться мате-

риальные и информационные объекты, образующие соответствующие потоки.

Материальный поток – непрерывное или дискретное множество матери-

альных объектов, распределенное во времени.

Информационный поток – множество информационных объектов, распре-

деленное во времени.

Информация, участвующая в процессах, операциях, действиях и деятельно-

сти в целом, может быть классифицирована:

1) ограничительная информация – сведения о том, что нельзя делать:

а) никогда, ни при каких обстоятельствах (кроме, быть может, форс-

мажорных), в любой фазе жизненного цикла и на любом этапе функционирова-

ния системы в целом;

б) в рамках функционирования конкретного блока.

Содержится в законах, подзаконных актах, международных, государствен-

ных и отраслевых стандартах, а также в специальных внутренних положениях и

документах предприятия, в частности, в технических требованиях, условиях,

регламентах и т.д.;

2) описательная информация – сведения об атрибутах объекта (потока),

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

и иных описаниях, реквизитах и других документах, являясь неотъемлемым

компонентом объекта в течение всего жизненного цикла. Эта информация сама

преобразуется (изменяется) в результате выполнения функции;




Часть I

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

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

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

3.2. Классификация функций, моделируемых блоками IDEF0

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

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

Основные виды функций

1. Деятельность (синонимы: дело, бизнес) – совокупность процессов, вы-полняемых (протекающих) последовательно или/и параллельно, преобразую-щих множество материальных или/и информационных потоков во множество материальных или/и информационных потоков с другими свойствами. Дея-тельность осуществляется в соответствии с заранее определенной и постоянно




Часть I

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

В модели IDEF0 деятельность описывается блоком А0 на основной контек-

стной диаграмме А – 0.

При моделировании крупных, многопрофильных структур (фирм, организа-

ций, предприятий), которые по своему статусу занимаются различными видами

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

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

грамме А – 1. В этом случае общая модель сложной структуры будет состоять

из ряда частных моделей, каждая из которых относится к конкретному виду

деятельности.

2. Процесс (синоним: бизнес-процесс) – совокупность последовательно

или/и параллельно выполняемых операций, преобразующая материальный

или/и информационный потоки в соответствующие потоки с другими свойст-

вами. Процесс протекает в соответствии с управляющими директивами, выра-

батываемыми на основе целей деятельности. В ходе процесса потребляются

финансовые, энергетические, трудовые, материальные ресурсы и выполняются

ограничения со стороны других процессов и внешней среды.

3. Операция – совокупность последовательно или/и параллельно выпол-

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

или/и информационного потока, в соответствующие объекты с другими свойст-

вами. Операция выполняется:

а) в соответствии с директивами, вырабатываемыми на основе директив,

определяющих протекание процесса, в состав которого входит операция;

б) с потреблением всех видов необходимых ресурсов;

в) с соблюдением ограничений со стороны других операций и внешней

среды.

4. Действие – преобразование какого-либо свойства материального или

информационного объекта в другое свойство. Действие выполняется в соот-

ветствии с командой, являющейся частью директивы на выполнение операции,




Часть I

с потреблением необходимых ресурсов и с соблюдением ограничений, нала-

гаемых на осуществление операции.

Дополнительные виды функций

5. Субдеятельность – совокупность нескольких процессов в составе дея-

тельности, объединенная некоторой частной целью (являющейся «подцелью»

деятельности).

6. Подпроцесс – группа операций в составе процесса, объединенная техно-

логически или организационно.

Основные виды функций образуют естественную иерархию блоков на IDE-

FO-диаграммах при декомпозиции, предусматривая четыре уровня последней

(см. прил. 1). При анализе сложных видов деятельности могут потребоваться

промежуточные уровни декомпозиции, основанные на применении дополни-

тельных видов функций.

Уровни декомпозиции, детализирующие действия, естественно считать со-

стоящими из элементарных или простых функций.

Одним из важных достоинств BPwin является возможность экспорта данных

функциональной модели в ПО фирмы Rockwell Software «Arena» с помощью

диаграммы IDEF3. Разработка и исследование имитационной модели на базе

существующей организационной и функциональной модели BPwin позволяет

проанализировать чувствительность модели по вероятностным отклонениям

параметров модели.




Часть I

Контрольные вопросы

1. Назначение «BPwin 4.1».

2. Дайте определение понятию «Блок».

3. Дайте определение понятию «Декомпозиция».

4. Дайте определение понятию «Диаграмма».

5. Дайте определение понятию «Стрелка» и перечислите основные типы

стрелок, применяемых при разработке модели.

6. Дайте определение понятию «Модель».

7. Дайте определение понятию «Система».

8. Опишите существующие отношения блоков на диаграммах IDEF0.

9. Назначение граничных стрелок.

10. Предназначение ICOM-кодирования.

11. Перечислите основные правила построения диаграмм.

12. Опишите принцип присвоения номера блоку.

13. Дайте классификацию функций, моделируемых блоками IDEF0.

14. Дайте определение понятию «Деятельность».

15. Дайте определение понятию «Процесс».

16. Дайте определение понятию «Операция».

17. Дайте определение понятию «Действие».




Часть I

ЧАСТЬ II

ИСПОЛЬЗОВАНИЕ ПО «ARENA»

ДЛЯ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ

ПРОЦЕССОВ УПРАВЛЕНИЯ СОВРЕМЕННЫМ ВУЗОМ

Основные положения

«Arena» Rockwell Software – программное обеспечение, позволяющее стро-

ить имитационные модели (прил. 3), проигрывать их и анализировать результа-

ты такого проигрывания. Универсальность подхода, заложенного в моделиро-

вании, обеспечивает построение моделей для самых разных сфер деятельности:

образовательных процессов, производственных технологических операций,

складского учета, банковской деятельности, обслуживания клиентов в рестора-

не и т.д. Особенность имитационного моделирования заключается в зависимо-

сти результатов модели от времени выполнения моделирования. Таким обра-

зом, полученная модель наиболее приближена к реальному моделируемому

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

ассоциируются с событиями. Проигрывание модели заключается в последова-

тельном переходе от одного события к другому. Обычно имитационные модели

строятся для поиска оптимального решения в условиях ограничения по ресур-

сам, когда другие математические модели оказываются слишком сложными.

Алгоритм моделирования с помощью ПО «Arena»:

1. Создание базовой модели. Для формирования модели процесса (мо-

дель «as is» – «как есть») Arena обеспечивает среду стиля – блок-схемы. Просто

перетащите модули Arena – формы в блок-схеме – в окно моделирования и

подключите их в порядке существующего потока процесса.




2. Наполнение модели данными. Добавьте данные (например время обра-

ботки, требования ресурса, уровни персонала) к Вашей модели, дважды нажи-

мая на модулях и прибавляя информацию в формы данных Arena. Чтобы созда-

вать более реалистическое изображение Вашей системы, замените значки муль-

типликации, которыми Arena автоматически обеспечивает Вашу модель (на-

пример, с ClipArt или других пакетов рисунка).

3. Моделирование модели. Выполните моделирование, чтобы проверить,

что модель должным образом отражает фактическую систему. Идентифицируй-

те критические параметры и свяжите их с другими через динамику графической

мультипликации Arena.

4. Анализ результатов моделирования. Arena обеспечивает автоматиче-

ские сообщения относительно общих критериев, например, использования ре-

сурса и времени ожидания. Прибавьте в модель встроенные статистические вы-

числения так, чтобы Arena сообщила, что является важным для принятия Вами

решений об объекте моделирования.

5. Выбор лучшей альтернативы. Сделайте изменения в модели, чтобы

фиксировать возможные сценарии, которые Вы хотите исследовать, затем

сравните результаты, чтобы найти наилучшее решение (модель «to-be» – «как

должно быть»).

Интерфейс программы «Arena»

Для работы в ПО «Arena» используют две основных области (рис. 14):

– модельную рабочую область: содержит всю модельную графику,

включая блок-схему технологического процесса, мультипликацию и другие

элементы рисунка. В нижней части модельной рабочей области находится

электронная таблица, в которой определены данные активных модулей, типа

времени, затрат и других параметров. При выделении любого модуля в мо-

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

го типа;




Часть II

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

Рис. 14

1. Концепции моделирования «Arena» Rockwell Software

Объекты и Атрибуты (Entities and Attributes). В каждой имитационной мо-дели существует не менее одного объекта, перемещающегося через систему моде-лирования. Каждый объект имеет собственные характеристики, называемые атри-бутами. Атрибуты могут быть назначены или изменены при выполнении различ-ных процессов, через которые проходят объекты. Возможно определить столько атрибутов, сколько необходимо для объектов в моделируемой системе.

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




Часть II

Имеются два типа очередей, используемых в Arena. Индивидуальные оче-

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

Объекты в этих очередях могут быть отображены в мультипликации; на них

могут быть собраны статистические вычисления; они могут быть ранжированы,

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

(когда используются с ресурсами) они могут быть разделены среди модулей.

Внутренние очереди обеспечивают накопление объектов при специфиче-

ском действии, но не обеспечивают мультипликацию, статистические вычисле-

ния и какие-либо механизмы.

Ресурсы (Resources) – постоянные элементы системы, которые могут быть

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

любой точке времени) и набор состояний (например, занятый, активный, неак-

тивный). В качестве ресурсов могут выступать люди, машины и т.д.

Терминология, связанная с ресурсами, следующая:

– когда объект требует ресурса, он занимает его (занятый ресурс);

– когда объект больше не требует ресурса, он освобождает его (свобод-

ный ресурс, простой ресурса);

– способность (емкость) ресурса ограничивает число объектов, которые

могут использовать его в любое время моделирования. Емкость ресурса может

изменяться во времени посредством графика значений емкости во времени.

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

использовать занятый ресурс.

Ресурсы изображены в мультипликации постоянным набором изображений,

представляющих состояние ресурса. Заданные по умолчанию изображения мо-

гут быть изменены, чтобы лучше представить состояние ресурса в процессе

моделирования.

Статистические вычисления (Statistics). Arena позволяет проводить ста-

тистические вычисления в процессе моделирования для любого элемента моде-

ли (например, очередей, ресурсов и т.д.). Результаты статистических вычисле-

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

как оно будет закончено.




Часть II

Наборы (Sets) обеспечивают обращение к группе подобных элементов модели через общее название. Например, ряд индивидуальных ресурсов (Иванов, Петров, Сидоров), представляющих преподавателей, может быть собран в набор по имени «Профессорско-преподавательский состав» (ППС). При необходимости использо-вания объектом (например, Курсант) ресурса «Преподаватель», он может исполь-зовать непосредственно ресурс по названию (Иванов) или может выбрать из числа всех доступных ресурсов преподавателей в наборе ППС.

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

Станции (Stations). Системы моделирования обычно имеют естественные границы, которые предлагают систематический подход сегментации в форми-ровании их представления. Например, производственная (образовательная) сис-тема обычно составляется из набора рабочих мест. Arena позволяет представ-лять системы, разделяя их в физические подсистемы, упомянутые как станции (места). Таким образом, каждая рабочая станция (администрация, деканат, ка-федра) в производственной модели представлена станцией в Arena.

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

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




Часть II

Транспортеры (Transporters) – тип устройства, которое перемещает объ-

екты через систему. Они могут использоваться, чтобы представить погрузочно-

разгрузочные работы или трансфертные устройства типа погрузчиков или

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

вать персонал, чье движение важно для системы моделирования (например

курсанты или ППС). Для использования транспортера необходимо иметь ин-

формацию, определяющую быстродействие транспортера и расстояние пере-

мещения между станциями, обслуживаемыми транспортером.

2. Краткий обзор среды разработки

модели в ПО «Arena»

Чтобы формировать модели с помощью Arena, необходимо использовать

формы моделирования, называемые модулями, панели Основного процесса (и

возможно другие панели разработки модели).

Имеется два типа модулей: модули типа Flowchart (схема производственно-

го процесса; схема последовательности процесса, схема информационных по-

токов, блок-схема; граф) и модули типа Data (Данные).

Формы модуля типа Flowchart размещаются в рабочей области мо-

делирования и связываются между собой, формируя тем самым

блок-схему, описывающую логику процесса. Для того, чтобы построить блок-

схему, необходимо перенести модули блок-схемы из панели Основного процес-

са в рабочую область моделирования и соединить их. Для редактирования мо-

дуля блок-схемы или дважды щелкают по модулю и затем формируют и запол-

няют форму, или редактируют данные в электронной таблице.

Модули типа Data не размещаются в модельном окне. Они содержат

данные модели и редактируются через интерфейс электронной таб-

лицы. Для того, чтобы редактировать данные, необходимо щелкнуть в панели

Основного процесса по необходимому модулю и затем отредактировать данные

в электронной таблице.




Часть II

2.1. Модули типа Flowchart

Assign module (Назначающий модуль) (табл. 1)

Этот модуль используется для присвоения новых значений пере-

менным, атрибутам объекта, типам объекта, изображениям объекта

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

сделаны одним Assign модулем.

Все объекты исходят от одиночного пункта вывода модуля. Для этого моду-

ля не имеется никаких анимационных переменных.

Таблица 1

Параметр Допустимые значения Значение по умолчанию

Name (Имя) – уникальный модульный идентифи-катор. Это название отображено на модульной форме.

Symbol Name [All Mod-ules]

<module name and instance number>

Assignments (Назначения) – определяет одно или большее количество назначений, которые будут сделаны объектом при выполнении модуля.

Type (Тип) – тип назначения, которое будет сде-лано.

Variable (переменная), Attribute (атрибут / свойство), Entity Type (тип объекта), Entity Picture (изобра-жение объекта), Other (другое)

Variable

Variable Name (Имя переменной) – название переменной, которой будет назначено новое зна-чение, когда объект входит в модуль. Применя-ется только в случае, когда Тип – Variable.

Symbol Name [Variables] Variable 1

Attribute Name (Имя атрибута) – название атри-бута объекта, которому будет назначено новое значение, когда объект пройдет модуль. Приме-няется в случае, когда Тип – Attribute.

Symbol Name [Attributes] Attribute 1

Entity Type (Тип объекта) – новый тип объекта, который будет назначен на объект, когда объект пройдет модуль. Применяется только, когда Тип – Entity Type.

Symbol Name [Entity Types]

Entity 1

Entity Picture (Изображение объекта) – новое изображение объекта, которое будет назначено на объект, когда объект входит в модуль. Приме-няется только, когда Тип – Entity Picture.

Symbol Name [Entity Pic-tures]

Picture. Report




Часть II

Окончание табл. 1


Other (Другое) – Идентифицирует специальную системную переменную, которой будет назначе-но новое значение, когда объект входит в мо-дуль. Применяется (обращается) только, когда Тип – Other.

Expression J

New Value (Новая стоимость) – значение атри-бута, переменной или другой системной пере-менной. Не применяется, когда Тип – Entity Type и Entity Picture.

Expression 1

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

Batch module (Модуль объединения) (табл. 2)

Этот модуль предназначен для группирования объектов в преде-лах имитационной модели. Пакеты объектов могут быть сгруппи-

рованы неизменно или временно. Временные пакеты должны быть позже раз-биты, используя модуль Separate (Разбиение), в переделах того же самого уров-ня подмодели. Пакеты могут быть сделаны с любым указанным количеством объектов или могут быть согласованы каким-либо атрибутом.

Объекты, достигающие Batch модуля, помещаются в очередь, пока не нако-пится требуемое число объектов. При достижении указанного числа создается новый объект – группа.

Таблица 2



Symbol Name [All Modules]


Type (Тип) – метод пакетирования объектов вместе.

Temporary (временно), Permanent (постоянно)

Permanent

Batch Size (Размер объединения) – число объ-ектов, которые нужно пакетировать.

Округленное до целого число

2




Часть II



Save Criterion (Объединение по критериям) – метод для назначения определяемых пользова-телем атрибутов со значением представитель-ского объекта.

First (первый), Last (по-следний), Sum (сумма), Product (произведение)

Last

Rule (Правило) определяет, как входящие объ-екты будут пакетироваться:

– группирование по порядковому номеру объ-ектов;

– группирование по соответствующему при-знаку, определенному Атрибутом. Например, ес-ли название Атрибута цветное, все объекты должны иметь тот же самый Номер цвета, кото-рый будет сгруппирован. Иначе, они будут ждать в модуле дополнительные входящие объекты.

Any Entityм (любой объект), By Attribute (по свойст-вам)

Any Entity

Attribute Name (Имя атрибута) – название атри-бута, чье значение должно соответствовать зна-чению других входящих объектов для группы, которая будет сделана. Применяется только, ко-гда Правило является Атрибутом.


Create module (Модуль формирования объектов) (табл. 3)

Этот модуль предназначен для формирования объектов в имитаци-

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

Schedule или формируются последовательно через заданное время. В этом мо-

дуле определяется Тип объекта и максимальное число объектов, создающихся

данным модулем.

Таблица 3


Name (Имя) – уникальный модульный иденти-фикатор. Это название отображено на модуль-ной форме.



Entity Type (Тип объекта) – название типа объ-екта, который будет сгенерирован.

Symbol Name [Entity Names]

Entity 1




Часть II



Type (Тип) – тип механизма генерирования объекта. Типы включают:

– случайный (использует экспоненциальное распределение, пользователь определяет среднее значение);

– список (график) (использует экспоненци-альное распределение по среднему значению, определенному в указанном модуле Schedule);

– константа (пользователь определяет по-стоянное значение, например 100);

– выражение (значение задается логическим или математическим выражением либо перемен-ной).

Random / Expo (Слу-чайный), Schedule (Список), Constant (Константа), Expression (Выраже-ние)

Random

Value (Стоимость) – определяет значение: – среднее экспоненциального распределе-

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

между поставками.

Real (действительные) 1

Schedule Name (Имя расписания) – определя-ет название Schedule, которое нужно использо-вать. График определяет поступление объектов в систему моделирования. Применяется только при выбранном Типе Schedule.

Symbol Name [Schedules]

Schedule 1

Expression (Выражение) – любое распределе-ние или значение, определяющее время между поставками. Применяется только при Типе – Выражение.

Expression (Distributions)

1

Units (единица) – единицы времени, исполь-зуемые для генерации двух последующих объ-ектов. Не применяется, когда Тип – График.

Seconds (секунды), Mi-nutes (минуты), Hours часы), Days (дни)

Hours

Entities per Arrival (Число по прибытию) – число объектов, которые введутся в систему.

Expression 1

Max Arrivals (Максимальное число) – макси-мальное число объектов, которые этот модуль генерирует. Когда это значение достигнуто, соз-дание новых объектов этим модулем прекраща-ется.

Expression Infinite (неопре-деленно)

First Creation (первое создание) – время на-чала генерирования первого объекта. Не при-меняется, когда Тип – График.

Expression 0.0




Часть II

Тип объекта будет автоматически добавлен в электронную таблицу Объекта.

Значения по умолчанию могут быть изменены: щелкнуть на модуль Объекта и

изменить указанный тип объекта.

Decide module (Модуль принятия решения) (табл. 4) Этот модуль учитывает процессы принятия решений в модели.

Включает параметры принятия решения, основанного на одном

или более количестве условий либо основанного на одном или более количест-

ве вероятностей (например, истина 75 %, ложь 25 %). Условия могут быть ос-

нованы на атрибутах со значением (например, Приоритет), на значениях пере-

менных, на типе объекта или выражении.

Модуль имеет два вывода, когда указанный тип принятия решения является

вероятностным или условным с 2 вариантами – «истина» или «ложь». Когда

существует несколько вариантов принятия решения с различными вероятност-

ными исходами или различными условиями, то модуль имеет множественные

выводы для каждого условия или вероятности и единый вывод «иначе».

Таблица 4 Параметр Допустимые значения

Значение по умолчанию

Name (Имя) – уникальный модульный иденти-фикатор. Это название отображено на модуль-ной форме.



Type (Тип) указывает, основано ли решение на условии (если > X) или имеет вероятностное рас-пределение (60 % да, 40 % нет). Тип может быть определен для 2 или более вариантов выводов. С 2 путями учитывает одно условие или вероятность (плюс «ложный» выход). На N направлений учи-тывается любое число условий или вероятностей, которые будут определены, и выход «иначе».

2-way by Condition (по условию 2 варианта), 2-way by Chance (слу-чайно 2 варианта), N-way by Condition (ус-ловие N вариантов), N-way by Chance (слу-чайно N вариантов)

2-way by Chance

Conditions (Условие) – определяет одно или большее количество условий, направляет объ-екты к различным модулям. Применяется толь-ко, когда Тип – N-way by Condition.

Percentages (Процентное отношение, рас-пределение) – определяет одно или большее количество вероятностных распределений, на-правляет объекты к различным модулям. При-меняется только, когда Тип – N-way by Chance.

Percent True (Процент правды) – значение, которое будет определять вероятность истинно-го принятия решения.

Expression (Various percentage alternatives)

50

�




Часть II



If (Если) – тип условия, на основании которого принимается решение.

Variable, Attribute, Entity Type, Expression

Entity Type (Тип логическо-го объекта)

Named (Именованный/ая) – определяет назва-ние переменной, атрибута или типа объекта, который будет оценен для принятия решения. Не применяется, когда Тип – Expression.

Symbol Name [Va-riables, Attributes, Entity Types]

Variable 1, Attribute 1, Entity 1

Is (быть) – условие оценки. Применяется только, чтобы выполнились условия Variable и Attribute.

>=, >, ==, <>, <, <= >=

Value (стоимость) – выражение, которое будет сравнено с атрибутом или переменной, или это одиночное выражение, определяющее – истина или ложь. Не обращается к условию Типа Объ-екта. Если Тип – Expression, это значение долж-но также включить вычислитель (например, Цвет < > Красный).

Expression 1

Имеются две области вывода, связанные с этим модулем. Объекты, которые

удовлетворяют условию «истина», выйдут от правой стороны модуля, в то вре-мя как при выполнении условий «ложь»/«иначе» объекты выйдут от дна моду-ля. Все пункты вывода должны быть связаны с другими модулями.

Dispose module (Модуль распределения) (табл. 5)

Модуль предназначен для окончания перемещения объектов в имитационной модели.

Таблица 5





Record Entity Statistics (Запись статистики объектов) – определяет возможность статисти-ческих вычислений для объекта. Статистические вычисления включают все показатели объекта.

Checked Unchecked

<Checked>

�




Часть II

Объекты, которые были созданы как временные пакеты, должны быть раз-

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

Dispose.

Process module (Процессный модуль) (табл. 6)

Этот модуль является главным, обрабатывающим события при

моделировании. В нем устанавливаются параметры для определе-

ния связей с ресурсом. Дополнительно имеется опция для использования типа

«подмодель». Время обработки события может рассматриваться как время, уве-

личивающее стоимость объекта, не увеличивающее стоимость, затрачиваемое

на передачу или ожидание, а также определенное другим типом. Стоимость

объекта будет добавлена к соответствующей категории показателей объекта.

Число объектов, которые находятся в настоящее время в процессе, определено

переменной «Process Name».WIP.

Все объекты выходят от одиночного пункта вывода модуля. Когда Тип мо-

дуля Процесса – Подмодель, в пределах модульной формы видна стрелка, ука-

зывающая на логику подмодели.

Таблица 6





Type (Тип) – метод определения логики в преде-лах модуля:

– Standard показывает, что вся логика будет сохранена в пределах модуля Процесса;

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

Standard (обычный), Submodel (подмодель)

Standard

Action (Действие) – тип обработки, которая про-изойдет в пределах модуля: – Delay указывает, что будет осуществлена за-держка процесса без использования ресурса;

Delay, Seize Delay, Seize Delay Release, Delay Release

Delay (Время)

D




Часть II

Продолжение табл. 6


– Seize Delay указывает, что ресурс будет ис-пользован и распределен в этом модуле, и осво-бождение ресурса произойдет в более позднее время;

– Seize Delay Release указывает, что ресурс будет распределен с задержкой процесса, и за-тем распределенный ресурс будет освобожден;

– Delay Release указывает, что ресурс пред-варительно был распределен и объект просто задержит и освободит указанный ресурс. Приме-няется только, когда Тип – Standard.

Priority (Приоритет) – приоритетное значение объекта, ожидающего в этом модуле для указан-ного ресурса. Используется, когда один или большее количество объектов от других модулей ожидают тот же самый ресурс. Не применяется, когда Action – Delay или Delay Release или когда Тип – Submodel.

High (1), Medium (2), Low (3), Other Expression

Medium (2)

Resources (Ресурсы) – перечисляет ресурсы или наборы ресурса, используемые для обработ-ки объекта. Не применяется, когда Action – Delay или когда Тип – Submodel.

Type (Тип) – технические требования специфи-ческого ресурса или набора ресурсов.

Resource Set

Resource

Resource Name (Имя ресурса) – название ре-сурса, который будет использоваться и/или вы-свобождаться. Применяется только, когда Тип – Resource.

Symbol Name [Re-sources]

Resource 1

Set Name (Имя набора) – название набора ре-сурса, элемент которого будет использоваться и/или высвобождаться. Применяется только, ко-гда Тип – Set.

Symbol Name [Resource Sets]

Set 1

Quantity (Число) – число ресурсов данного на-бора или от данного набора, которое будет ис-пользоваться/освобождаться. Для наборов это значение определяет только номер выбранного ресурса, который будет использоваться / осво-бождаться, не число членов набора.

Expression Truncated to Integer

1

Selection Rule (Правило выбора) – метод вы-бора доступных ресурсов в наборе:

– Cyclical – циклический перебор доступных членов;

Cyclical, Random, Preferred Order, Specific Member,

Cyclical




Часть II

Продолжение табл. 6


– Random – случайный беспорядочный выбор элемента;

– Preferred Order – привилегированный поря-док, который будет всегда выбирать первый дос-тупный элемент;

– Specific Member требует, чтобы параметр Save Attribute определил элемент набора, кото-рый должен быть выбран (предварительно со-храненный в поле Save Attribute);

Largest Remaining Capacity и Smallest Number Busy используются для ресурсов с множествен-ной способностью. Применяются в случае, когда Тип – Set.

Largest Remaining Ca-pacity, Smallest Number Busy

Save Attribute – название Атрибута, определяющее индекс элемента в наборе, который должен быть выбран. Этот атрибут также может быть определен правилом отбора Элемента, при условии, что Пра-вило отбора будет отличным от существующих.

Symbol Name [Attributes]

Set Index (Набор индексов) – индекс требуемо-го элемента в наборе. Применяется только, когда Правило отбора – Specific Member. Если Action определено как Delay Release, указанное значе-ние определяет элемент набора, который дол-жен быть освобожден от использования.

Expression 1

Delay Type (Тип задержки) – тип распределения или метода определения параметров задержки. Constant и Expression требуют одиночных значе-ний, в то время как Normal, Triangular и Uniform требуют нескольких параметров.

Constant, Normal, Triangular, Uniform, Expression

Triangular

Units (Единица) – единицы времени для пара-метров задержки.

Seconds, Minutes, Hours, Days

Hours

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

Value Added, Non Value Added, Transfer, Other, Wait

Value Added




Часть II



Minimum (Минимум) – поле Parameter для оп-ределения минимального значения для Triangu-lar и Uniform распределения.

Expression 0,5

Value (Стоимость) – поле Parameter для опре-деления среднего для распределения Гаусса, значения для Постоянного запаздывания или режима для Треугольного распределения.

Expression 1

Maximum (Максимум) – поле Parameter для оп-ределения максимального значения для Triangu-lar и Uniform распределения.

Expression 1,5

Std Dev – поле Parameter для определения среднеквадратичного отклонения для нормаль-ного закона распределения.

Expression 0,2

Expression (Выражение) – поле Parameter для определения выражения, чье значение оценено и используется для запаздывания обработки.

Expression 1

Report Statistics (Статистический отчет) – оп-ределяет, будут или нет статистические вычис-ления автоматически собраны и сохранены в ба-зе данных для этого процесса.

Checked, Unchecked

<Checked>

При использовании процессом ресурса, он автоматически добавляется к

электронной таблице, используя значения по умолчанию. Модуль Ресурса мо-

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

ресурса.

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

добавлен к электронной таблице. Набор не будет содержать никаких членов, и

модуль Набора должен быть отредактирован, иначе Arena сообщит об ошибке:

«Этот модуль не был отредактирован».

Освобождение ресурсов после их использования будет производиться в по-

рядке, противоположном тому, в котором эти ресурсы были распределены объ-

екту (объектами). Приоритетное поле модуля используется в случае ожидания

использования единого ресурса множеством процессов.




Часть II

Имеются пять параметров стоимости и распределения времени в пределах

модуля Процесса: Добавленная стоимость (VA), Недобавленная стоимость

(NVA), Передача (Transfer), Ожидание (Wait) и Другой (Other). Процесс может

иметь любую комбинацию типов распределения, если он содержит подмодель,

поскольку подмодели могут быть составлены из множественных модулей Про-

цесса.

Все статистические вычисления Процесса, типа синхронизации и стоимости,

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

Переменная «Process Name».NumberIn автоматически создается модулем

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

ременная «Process Name».NumberOut автоматически создается модулем Про-

цесса и увеличивается каждый раз, когда объект оставляет Процесс.

Record module (Модуль записи) (табл. 7)

Модуль используется в имитационной модели для статистических

вычислений.

Доступны различные типы наблюдательных статистических вычислений,

включая время между выходами объектов из модуля, статистические вычисле-

ния объекта (время, стоимость и т.д.), общие наблюдения, интервальные стати-

стические вычисления (от некоторой временной метки до текущего времени

моделирования).

Таблица 7





Type (Тип) – подсчет или сбор статистической информации:

– Count увеличивает или уменьшает значение определенной переменной;

– Entity Statistics генерирует общую статистику объекта, например информацию о времени и от-ношении стоимость/длительность;

Count, Entity Statistics, Time Interval, Time Between, Expression

Count

D




Часть II



– Time Interval вычисляет и сохраняет интер-вал времени между определенной величиной и текущим временем моделирования;

– Time Between отслеживает и сохраняет зна-чение времени между объектами, входящими в указанный модуль;

– Expression сохраняет величину определен-ного выражения.

Attribute Name (Имя атрибута) – название атри-бута, значение которого будет использоваться для статистического измерения интервала. При-меняется только, когда Тип – Time Interval.


Value (Стоимость) – значение, на которое будет увеличено или уменьшено наблюдаемое значение, когда Тип – Expression или когда Тип – Count.

Expression 1

Tally Name (Имя ярлыка) – поле определяет на-звание символа, в которое должно быть зареги-стрировано значение наблюдения.

Symbol Name [Tallies] Record 1

Counter Name (Имя счетчика) – поле определя-ет название счетчика.

Symbol Name [Counters] Record 1

Record into Set (Запись в наборе) – переключатель, определяющий использование числа или набора.

Checked, Unchecked <Unchecked>

Tally Set Name – название набора чисел, кото-рый будет использоваться, чтобы делать запись о статистических наблюдениях.

Symbol Name [Tally Sets] Tally Set 1

Counter Set Name – название набора, который будет использоваться для записи индекса.

Symbol Name [Counter Sets]

Counter Set 1

Set Index (Индекс набора) – индекс итогового числа или набора счетчиков.

Expression (Attributes) 1

Separate module (Модуль разбиения) (табл. 8)

Модуль предназначен для копирования входящего объекта или для

разбивания предварительно созданного пакетного объекта. В моду-

ле определяется правилом: при разбивании временных пакетов, которые были

сформированы ранее, объекты последовательно выходят из модуля в том же

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

�




Часть II

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

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

Таблица 8





Type (Тип) – метод отделения входящего объекта: – Duplicate Original будет делать некоторое

число копий первоначального объекта; – Split Existing Batch требует, чтобы входящий

объект был временным пакетным объектом, по-лученным Batch модулем. Временный пакет бу-дет разбит на первоначальные объекты.

Duplicate Original (дуб-ликат оригинала), Split Existing Batch (раз-биение на составляю-щие)

Duplicate Origi-nal

Percent Cost to Duplicates – распределение за-трат и времени входящего объекта к уходящим дубликатам. Это значение равно проценту от за-трат и времени первоначального объекта (между 0 – 100). Указанный Процент будет разбит рав-номерно между дубликатами, в то время как пер-воначальный объект сохранит любой остающий-ся процент – стоимость / время. Применяется только в случае, когда Тип – Duplicate Original.

Expression 50

# of Duplicates (Число копий) – число уходящих объектов, которые выдаст модуль, в дополнение к первоначальному входящему объекту. Применяет-ся только в случае, когда Тип – Duplicate Original.

Expression 1

Member Attributes – метод определения предста-вительских атрибутов со значением объекта на первоначальные объекты. Эти параметры касаются шести из специальных атрибутов объектов (Enti-ty.Type, Entity.Picture, Entity.Station, Entity.Sequence, Entity.Jobstep и Entity.HoldCostRate). Применяется только в случае, когда Тип – Split Existing Batch.

Retain Original Entity Values, Take All Representative Values, Take Specific Repre-sentative Values

Retain Original Entity Values




Часть II



Attribute Name – название представительского атрибута объекта, который назначен на первона-чальные объекты группы. Применяется только в случае, когда Member Attributes – Take Specific Representative Values.

Symbol Name [Attributes]

Attribute 1

Если # of Duplicates меньше 1 или равно 0, никакие двойные объекты не

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

Duplicates, будут разбиты равномерно между дубликатами, в то время как пер-

воначальный объект сохранит любую остающуюся стоимость и процент време-

ни. Например, если Стоимость к Дубликатам – 50, # of Duplicates – 2, 25 %

стоимости входящего объекта, а нормы времени будут распределены и сохра-

нены между каждым из дубликатов, 50 % затрат входящего объекта и времени

будут распределены оригиналу. Точно так же, если Стоимость к Дубликатам –

90, # of Duplicates – 3, каждый дубликат будет иметь 30 % входящих затрат и

времени объектов, в то время как оставшиеся 10 % будут сохранены первона-

чальным входящим объектам.

Когда объекты отделены, оригинал и все дубликаты имеют тот же самый ат-

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

того, чтобы собрать объекты соответствия после окончания параллельной об-

работки.

2.2. Модули типа Data

Entity module (табл. 9)

Модуль определяет различные типы объектов, их начальные формы анима-

ции в моделировании, информацию о стоимости и затратах объекта.




Часть II

Таблица 9


Entity Type – название определяемого типа объ-екта. Это название должно быть уникально.



Initial Picture – графическое представление объ-екта в начале моделирования. Это значение мо-жет быть изменено в течение моделирования посредством Assign модуля.

Symbol Name [Pictures] Picture.Report

Holding Cost/Hour – Почасовые затраты обра-ботки объекта в системе. Эта стоимость изменя-ется, когда объект находится в системе модели-рования.

Real 0.0

Initial VA Cost – значение Капитальных затрат, которое будет назначено на атрибут добавлен-ной стоимости объекта. Этот атрибут накаплива-ет затраты, когда объект находится в действии.

Real 0.0

Initial NVA Cost – значение Капитальных затрат, которое будет назначено на атрибут недобав-ленной стоимости объекта.

Real 0.0

Initial Waiting Cost – значение Капитальных за-трат, которое будет назначено на ожидающий атрибут стоимости объекта. Этот атрибут накап-ливает понесенные затраты, когда объект прово-дит время в действии, например ожидает ресурс в модуле Процесса.

Real 0.0

Initial Transfer Cost – значение Капитальных за-трат, которое будет назначено на трансфертный атрибут стоимости объекта. Этот атрибут накап-ливает понесенные затраты, когда объект нахо-дится в процессе транспортировки.

Real 0.0

Initial Other Cost – значение Капитальных за-трат, которое будет назначено на другой атрибут стоимости объекта.

Real 0.0

Report Statistics – определяет, будут или нет статистические вычисления автоматически соб-раны и сохранены в базе данных сообщений для этого типа объекта.

Checked, Unchecked <Checked>

Для каждого объекта начальное изображение, которое определено, должно иметь соответствующее графическое представление. Если графическое пред-ставление не определено, то объект не будет мультиплицирован в процессе мо-делирования.




Часть II

Названия Объекта, введенные через Create модуль, автоматически добавля-ются к электронной таблице объекта. Если данные объекта не отредактированы через модуль Объекта, он будет иметь значения по умолчанию для стоимост-ных параметров.

Начальная VA стоимость, NVA стоимость, стоимость ожидания, транспор-тировки и другие, указанные в этом модуле, автоматически назначаются на ат-рибуты стоимости объекта. Эти затраты не включаются в системные итоговые статистические вычисления.

Queue module (табл. 10)

Этот модуль может использоваться для изменения правила указанной оче-реди. Значение по умолчанию, ранжирующее правило для всех очередей: «Пер-вым прибыл – первым обслужен».

Таблица 10


Name – название очереди. Это название должно быть уникально.

Symbol Name [Queues] <module name and instance number>

Type – правило ранжирования для очереди, кото-рая может быть основана на атрибуте. Типы включают порядок очереди: FIFO, LIFO, Lowest Attribute Value и Highest Attribute Value. Низкое значение атрибута может быть 0 или 1, в то время как высокое значение может быть 200 или 300.

First In First Out, Last In First Out, Lowest Attribute Value, Highest Attribute Value

First In First Out

Attribute Name – атрибут, который будет оценен для Lowest Attribute Value или Highest Attribute Value. Объекты с самыми низкими или самыми высокими значениями атрибута будут ранжиро-ваны в очереди.


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

Checked, Unchecked Unchecked

Report Statistics – определяет, будут или нет статистические вычисления автоматически соб-раны и сохранены в базе данных сообщений для этой очереди.





Часть II

FIFO и LIFO обеспечивают самое быстрое время выполнения моделирования. Общедоступные очереди могут использоваться для имеющихся ресурсов.

Resource module (табл. 11)

Этот модуль определяет ресурсы в системе симуляции, включая информацию о стоимости и доступность (готовность) ресурса. Ресурсы могут иметь закреп-ленную способность, которая не изменяется в модели или может оперировать, используя Schedules. Неисправности Ресурса и состояние могут также вызывать-ся в этом модуле для использования с Расширенным Процессом и Расширенным Перемещаемым поддоном (недоступный в Основном издании Arena).

Таблица 11


Name – название ресурса, характеристики кото-рого определяются. Это название должно быть уникально.

Symbol Name [Resources]


Type – метод для определения способности ре-сурса:

– Fixed Capacity: не будет изменяться в тече-ние работы модели;

– Based on Schedule показывает, что исполь-зуется модуль Schedule, чтобы определить спо-собность и информацию продолжительности для ресурса.

Fixed Capacity, Based on Schedule

Fixed Capacity

Capacity – число модулей ресурса данного на-звания, которые являются доступными системе для обработки. Применяется только, когда Тип – Fixed Capacity.

Integer 1

Schedule Name – идентифицирует название Schedule, которое нужно использовать ресурсом. Список (график) определяет способность (вме-стимость) ресурса для данного промежутка вре-мени. Применяется (обращается) только, когда Тип – Список (график).

Symbol Name [Schedules]

Schedule 1

Schedule Rule – диктует, когда фактическое из-менение способности должно произойти, когда уменьшение в способности требуется для заня-того модуля ресурса. Применяется только, когда Тип – Schedules.

Ignore, Wait, Preempt Wait




Часть II



Busy/Hour – стоимость в час ресурса, который обрабатывает объект. В течение времени, когда ресурс занят, стоимость его накапливается. За-нятая стоимость в час автоматически преобразу-ется к соответствующей основной единице вре-мени, указанной в пределах Параметров Дубли-рования (страница пункта меню Run/Setup).

Real 0.0

Idle/Hour – стоимость в час ресурса, который явля-ется неактивным. В течение времени, когда ресурс не активен, стоимость накапливается на основании стоимости простоя / часа. Неактивная стоимость в час автоматически преобразована (конвертирована) к соответствующей основной единице времени, ука-занной в пределах Параметров Дублирования (страница пункта меню Run/Setup).

Real 0.0

Per Use – стоимость ресурса на основании ис-пользования, независимо от времени, в течение которого ресурс используется. Каждый раз, когда ресурс распределен объекту, это будет вклю-чаться в стоимость использования.

Real 0.0

StateSet Name – название состояния набора; оз-начает, что ресурс может быть назначен в тече-ние прогона модели. Это свойство не доступно в Основном издании Arena.

Symbol Name [StateSets]

(None defined)

Initial State – начальное состояние ресурса. Если определено, название должно быть определено в пределах группы повторений существующих названий. Это поле показывается только, когда название StateSet определено.

Symbol Name [States] (Idle or Inactive state, depend-ing on capacity specified)

Failures – перечисляет все неисправности, кото-рые будут связаны с ресурсом. Это свойство не доступно в Основном издании Arena.

Failure Name – название неисправности, связан-ной с ресурсом.

Symbol Name [Failures] Failure 1

Failure Rule – диктует поведение, которое долж-но произойти, когда неисправность должна про-изойти для занятого модуля ресурса.

Ignore, Wait, Preempt

Ignore

Report Statistics – определяет, будут или нет статистические вычисления автоматически соб-раны и сохранены в базе данных сообщения для этого ресурса.





Часть II

Ресурсы, которые перечислены как члены набора ресурсов в электронной таблице Набора, автоматически добавлены к электронной таблице Ресурса со значениями по умолчанию. Эти значения по умолчанию могут быть изменены, редактируя электронную таблицу Ресурса.

Когда доступность (готовность) ресурса основана на Schedule, указанное на-звание Schedule автоматически добавлено к электронной таблице Schedule. Мо-дуль Schedule должен быть отредактирован со значением и информацией про-должительности, введенной для ресурса, который нужно использовать. Имита-ционная модель будет работать, если заданный по умолчанию Schedule не отре-дактирован, однако, способность ресурса будет принята нулевой. Это может быть графически идентифицировано в модели. Schedule должен быть типа «способности» Schedule.

Schedule module (табл. 12)

Этот модуль может использоваться вместе с модулем Ресурса, чтобы опре-делить оперативный график для ресурса, или с Assign модулем, чтобы опреде-лить Schedule достижения. Дополнительно Schedule может использоваться и вызываться, чтобы разложить на множители запаздывания, основанные на си-муляции времени.

Таблица 12


Name – название определяемого Schedule. Это название должно быть уникально.

Symbol Name [Sche-dules]


Type – тип определяемого Schedule. Это может быть связанная Capacity (для Schedule ресурса), связанное достижение (для Assign модуля) или Other (разные запаздывания или коэффициенты (факторы)).

Capacity, Arrival, Other

Capacity

Time Units – единицы времени, используемые для информации длительности.

seconds, minutes, quarterhours, halfhours, hours, days

hours




Часть II



Scale Factor – метод масштабирования Schedule для увеличений или уменьшений. Поля заданной величины будут умножены на коэффициент, что-бы определить новые значения.

Real 1.0

Durations – перечисляет значение и пары про-должительности для Schedule. Значения могут быть Capacity, Arrival или другие значения типа, в то время как продолжительность определена в модуле. Пары Schedule повторятся после того, как все продолжительности будут закончены, ес-ли последняя продолжительность не оставлена (бесконечным) пробелом. Данные Schedule могут быть введены графически, используя графиче-ский редактор Schedule, или вручную, используя поля Value/Duration.

Ignore, Wait, Preempt

Wait

Value (Capacity) – представляет Capacity ресур-са (если Тип – Capacity), частоту поступления (если Тип – Arrival) или некоторое другое значе-ние (если Тип – Other).

Expression 1

Duration – длительность, для которой заданная величина будет правильна (допустима).

Expression Infinite

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

мыши на столбце Duration для специфического Schedule и затем выбирая Edit через Диалог. Эта форма ввода данных требуется в случае, когда длительности – не целое число (например 3.57 протокол) или длительность определяется вы-ражением (например стохастическая длительность подобно ЭКСПО (5.8)).

При использовании Schedule типа Arrival указанное значение – это число поставок в час. Независимо от основных единиц времени симуляции, указан-ных в диалоге Параметров Дублирования.

Поле коэффициента Ламе доступно только для Arrival и Other (тип Schedule). При использовании Schedule Arrival значения (не продолжительно-сти) будут умножены на коэффициент Ламе.

Другой тип Schedule требует функции SchedValue («Name Schedule»), чтобы обратиться к информации Schedule изнутри модели.




Часть II

Set module (табл. 13)

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

число, тип объекта и изображение объекта.

Таблица 13


Name – название определяемого набора. Это название должно быть уникально.

Symbol Name [Sets] <module name and instance number>

Type – тип определяемого набора. Resource, Counter, Tally, Entity Type, Entity Picture

Resource

Members – перечисляет ресурс, тип объекта или объект в пределах набора.

Resource Name – название ресурса в пределах набора ресурсов. Применяется только, когда Тип – Resource.

Symbol Name [Re-sources]

Resource 1

Tally Name – название числа в пределах набора чисел. Применяется только, когда Тип – Tally.

Symbol Name [Tallies] Tally 1

Counter Name – название счетчика в пределах встречного набора. Применяется только, когда Тип – Counter.

Symbol Name [Counters] Counter 1

Entity Type – название типа объекта в пределах набора типов объектов. Применяется только, ко-гда Тип – Entity Type.

Symbol Name Entity 1

Picture Name – название изображения в преде-лах набора изображений. Применяется только, когда Тип – Entity Picture.

Symbol Name Picture.Report

Ресурсы, перечисленные как члены набора ресурсов, автоматически добав-

лены к электронной таблице Ресурса со значениями по умолчанию, которые могут быть изменены с помощью редакции электронной таблицы Ресурса.

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




Часть II

Variable module (табл. 14)

Этот модуль используется при определении размеров переменной и ее пер-

воначального значения. Переменные могут вызываться в других модулях (на-

пример Decide модуль), могут быть переназначены новым значением Assign

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

Таблица 14


Name – название определяемой переменной. Это название должно быть уникально.

Symbol Name [Variables] <module name and instance number>

Rows – число строк в размерной переменной. Integer (no rows) Columns – число столбцов в размерной пере-менной.

Integer (no columns)

Report Statistics – переключатель для опреде-ления, будут или нет статистические вычисления собраны и сохранены в базе данных для этой переменной.


Clear Option – определяет время, при котором значение переменной будет возвращено к пер-воначальному значению:

– Statistics: сбросить переменную к первона-чальному значению всякий раз, когда статисти-ческие вычисления очищены;

– System: сбросить переменную к первона-чальному значению всякий раз, когда система инсталлирована заново;

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

Statistics, System, None

System

Initial Values – перечисляет первоначальное значение переменной. Это значение может быть изменено с Assign модулем.

Initial Value – переменное значение в начале си-муляции.

Real 0.0




Часть II

3. Созддание ммодели

Имиттационнаяя модель ообязателььно включчает следуующие основные эллементы:

1. И

мация ил

обычно з

Источник

ли объект

задается с

ки (Create

ты. Скоро

статистич

e) – элеме

ость пост

ческой фу

енты, от к

тупления

ункцией.

которых в

данных и

в модель

или объек

поступае

ктов от и

ет инфор-

источника

-

а

2. ССтоки (Diispose) – уустройствва для прииема инфформации или объеектов.

3.

имитаци

Процессы

ионной мо

ы (Proces

одели мож

s) – это

жет быть

аналог р

задана пр

абот в ф

роизводит

функциона

тельность

альной м

ь процесс

модели. В

ов.

В

4.

понятию

в разных

цессами

имитаци

очередях

Тип о

–

первыми

–

правляю

Могу

Прост

Очереди

ю хранили

х процесс

могут на

ионного м

х.

(Queue)

ища данны

сах может

капливат

моделиров

– место,

ых). Врем

т быть ра

ься объек

вания явл

где объе

мя обрабо

азным. В

кты, ожид

ляется ми

екты ожи

отки объе

результа

дающие с

инимизац

идают обр

ектов (про

ате перед

воей очер

ция колич

работки (

оизводите

некоторы

реди. Час

чества об

(близко к

ельность)

ыми про-

то целью

бъектов в

к

)

-

ю

в

очереди вв имитациионной моодели можжет быть конкретиизирован:

очередь п

и отправля

последов

тся объек

ут быть за

тейшая и

похожая

яются на д

вательная

кты, приш

аданы и бо

митацион

на стек:

дальнейш

объекты,

шую обраб

пришедш

ботку (LIF

шие в оче

FO: last-in-

ередь пос

-first-out);

следними,

,

я обработ

шедшие п

олее слож

нная моде

тка: первы

ервыми (

жные алго

ель, созда

Рис. 15

ыми на д

FIFO: firs

дальнейшу

st -in-first-

ую обраб

-out).

ботку от--

оритмы обработкии очереди..

анная в Arrena, покаазана на ррис. 15.




Часть II

Для плитру инщелкнутинструме

построенинструменть по кноентов (ри

ия моделетов, набопке New ис. 16), ко

ей Arena ор гидов на панел

оторая сод

имеет наи др. Длли инструдержит дв

бор средсля созданументов. ва типа мо

ств, которния моделСлева поодулей.

рые вклюли сначалоявляется

ючают па-ла нужноя палитра

-о а

Рис. 16

Моду

быть пер

не могут

стройки

нижней ч

Перен

ному мо

ются авт

Create яв

товление

на конве

может им

ется сток

делий с к

ули типа

ренесены

т быть ра

параметр

части мод

несем из

одулю Cre

томатиче

вляется и

е изделий

ейер. Мод

митирова

ком сущн

конвейера

Flowchart

на рабоче

азмещены

ров моде

дели, когд

панели и

eate, Disp

ски (хотя

источнико

й, то мод

дуль Proc

ать станок

ностей из

а.

t служат

ее простр

ы в рабоч

ели. Окно

да фокус

инструме

pose и Pr

я могут б

ом сущно

дуль Crea

cess отвеч

к, обраба

системы.

для отоб

ранство м

чее прост

о редакти

установл

бражения

модели dra

транство

ирования

лен на мод

потоков

ag&drop. М

модели

парамет

дуле типа

объектов

Модули т

и служат

тров появ

а Data.

в и могут

типа Data

т для на-

вляется в

т

a

-

в

нтов в ра

ocess. Св

быть и п

остей в си

ate может

чает за об

атывающи

. Он може

абочее пр

вязи межд

переопред

истеме. Та

т описыва

бработку

ий загото

ет модели

ространст

ду модул

делены вр

ак, если о

ать посту

сущност

овки. Мод

ировать с

тво модел

лями уста

ручную).

описывае

упление з

тей. Напр

дуль Disp

снятие гот

ли по од-

анавлива-

Модуль

ется изго-

заготовок

ример, он

pose явля-

товых из-

-

-

ь

-

к

н

-

-




Часть II

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

Рис. 17

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

Рис. 18




Часть II

Модель показывает систему обработки документа (закладной). Сначала до-

кумент регистрирует секретарь, затем просматривает клерк, который либо при-

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

набора иконок сверху от процесса Review Application и в виде графика в правой

нижней части рисунка. Иконки, отображающие секретаря и клерка, могут быть

разными в зависимости от состояния (занят – ожидает), следовательно, модель

может быть анимирована.

Создавать имитационные модели без предварительного анализа бизнес-

процессов не всегда представляется возможным. Действительно, не поняв сути

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

кретные технологические процессы. Поэтому функциональные и имитацион-

ные модели не заменяют, а дополняют друг друга, при этом они могут быть

тесно взаимосвязаны.

Имитационная модель дает больше информации для анализа системы, в

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

модели процессов. Наиболее целесообразно сначала создать функциональную

модель, а затем на ее основе строить модель имитационную.

Контрольные вопросы

1. Назначение ПО «Arena».

2. Последовательность моделирования с помощью ПО «Arena».

3. Интерфейс программы «Arena».

4. Опишите типы модулей, используемых при моделировании процессов с

помощью программного комплекса «Arena».

5. Перечислите модули типа Flowchart.

6. Перечислите модули типа Data.




Часть II

ЧАСТЬ III

РЕКОМЕНДАЦИИ ПО ПРОВЕДЕНИЮ

ПРАКТИЧЕСКИХ ЗАНЯТИЙ С ИСПОЛЬЗОВАНИЕМ

ПРОГРАММНЫХ КОМПЛЕКСОВ «BPWIN» «ARENA»

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

лективы (подгруппы) по 3-4 человека.

Задание и исходная информация выдается преподавателем (примеры зада-

ний приводятся ниже).

По итогам работы каждая подгруппа формирует базу данных и отчет о про-

деланной работе, который включает в себя:

1. Исходные данные, требуемые результаты исследования.

2. Структура функциональной модели образовательного процесса УВАУ ГА

и ее описание.

3. Структура имитационной модели образовательного процесса УВАУ ГА

и ее описание.

4. Анализ результатов имитационного моделирования на конкретном

примере.

5. Выводы о проделанной работе.

Задания к практическим занятиям

1. Изучить структуру и логику имитационной модели образовательного

процесса УВАУ ГА. Изучить отчет, генерируемый программным комплексом

«Arena» по окончании проигрывания модели.




2. На основе исходной статистической информации произвести расчет пока-

зателей:

– состав ППС;

– обеспеченность учебно-методической литературой;

– количество курсантов на одного преподавателя;

– мотивация.

Внести полученные значения показателей в имитационную модель и запустить

ее, сгенерировать отчет по итогам проигрывания модели. Полученные значения

внести в базу данных. Изменить исходные данные / показатели и организовать

новое проигрывание модели; полученные данные также внести в базу данных.

На основе полученных данных провести оптимизацию структуры образова-

тельного процесса.

№ п/п

Наименование по-казателя

Вариант 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1

Состав ППС

, % Профессор 20 10 5 30 15 15 5 12 25 0 15 20 10 20 7

Доцент 45 20 50 30 10 25 40 20 25 10 25 50 0 50 13

Ст. препода-ватель

30 60 40 40 50 50 45 50 25 80 10 25 90 0 58

Ассистент 5 10 5 0 25 10 10 18 25 10 30 5 0 30 22

2 Количество курсан-тов в группе на од-ного преподавате-ля, чел.

30 15 20 26 10 17 23 12 19 24 28 11 29 14 21

3

Мотивация

, %

ГСД 25 30 35 40 65 50 85 60 50 70 75 80 85 90 45

ОПД 30 40 50 60 70 50 90 45 65 60 55 75 80 95 45

ЕНД 40 35 40 55 80 50 75 45 40 55 70 60 70 90 40

ДС значимые 60 70 50 75 90 50 100 75 80 90 100 90 90 100 60

ДС менее зна-чимые

50 70 45 60 90 50 90 60 65 85 90 90 85 100 60

СД значимые 60 70 55 80 85 50 95 60 75 85 95 85 90 100 80

СД менее зна-чимые

50 70 50 70 85 50 85 60 50 80 95 75 90 100 75




Часть III

Для ввода в модель показателя «качественный состав ППС (Кэф)» необходи-мо рассчитать коэффициент профессионального уровня профессорско-преподавательского состава выпускающей кафедры или вуза.

Соотношение должностей ППС:

Должность Количество, % Разряд ЕТС профессор 10 16 доцент 45 14

стар. преподаватель 39 13 ассистент 6 9

узп

пвэф К

ККК ⋅= ;

где Кэф – коэффициент эффективности подготовки специалистов;

Кпв – коэффициент профессионального уровня подготовки специалистов, его

величина лежит в пределах от 0 до 1 и определяется отношением среднего бал-

ла к величине максимальной оценки в баллах (5 баллов);

Кп – коэффициент профессионального уровня ППС выпускающей кафедры

или вуза. Величина коэффициента для преподавательских должностей лежит в

пределах от 0,5 до 1 и определяется отношением среднего значения тарифного

коэффициента ЕТС преподавательских должностей кафедры к значению макси-

мального тарифного коэффициента преподавательской должности профессора;

Куз – коэффициент увеличения знаний в процессе обучения за счет положи-

тельной обратной связи обучаемого (при макроанализе принимается Куз = 1).

3. Построить имитационную модель учебного процесса для группы курсан-

тов, учитывая следующие условия:

– учебный процесс состоит из 10 семестров;

– начальное количество курсантов 30 человек;

– каждый семестр состоит из 4-х блоков: 18-ти недельное обучение, за-

четная неделя, сессия и каникулы;

– отчисление производится вероятностным способом (5 %), только при

условии 3-й неудачной попытки сдачи зачета или экзамена;

– учебный процесс организован блочно, с учетом времени подготовки на

каждый блок.




Часть III

Оформление практической работы

Титульный лист должен быть оформлен по образцу (прил. 4). После титуль-

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

Далее идет описание структуры и логики данной модели образовательного

процесса УВАУ ГА.

Работа выполняется на листах писчей бумаги формата А4 и брошюруется. К

работе прикладываются необходимые графики, схемы, рисунки, таблицы, кото-

рые брошюруются совместно с листами пояснительной записки при формиро-

вании отчета. Рисунки и прочие графические материалы снабжаются подрису-

ночными подписями.

Текст работы пишется на одной стороне листа писчей бумаги. Нумерация

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

страницу (номер на ней не ставится). Номер страницы ставится в верхнем пра-

вом углу.

На каждой странице текста должны быть поля (слева – 20 мм, сверху, снизу,

справа – по 10 мм).

На титульном листе ставятся дата и подпись курсанта (студента), выпол-

нившего работу.

В конце работы должен быть чистый лист для замечаний, рекомендаций и

заключения преподавателя по работе.




Часть III

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. ГОСТ Р50.1.028-2001. Информационные технологии поддержки жизнен-

ного цикла продукции. Методология функционального моделирования. – М.:

Госстандарт России: Изд-во стандартов, 2001.

2. Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process

Modeler / С.В. Маклаков. М.: Диалог – МИФИ, 2003.




П Р И Л О Ж Е Н И Я




Приложение 1

Фуннкциональнная модельь образоваттельного прроцесса УВВАУ ГА

Рис. 1. Контекстнная диаграммаа верхнего уровня




Рис. 2. Веррхняя дочерняя диаграмма




Рис. 3. ДДочерняя диагррамма А2




Рис. 4. Дочерняя диаграамма А2.1




Диааграмма ID

DEF3






Наборкурсантов

Формированиегрупп

Окончание учебногопроцесса Учебный процесс

ГСД

Учебный процессенд

Учебный процессОПД

Учебный процессСД

Учебный процессДС

Выделение курсантов

Провести зачетную неделю

Сданы всезачеты

Проведение сессии

Сессиясдана?

T r u e

Fa l se

Практики

Контрользнаний

Практика сдана

Теоретическое и практическое обучение не пройдено?

Каникулы

Переход в следующий семестр

T r u e

Fa l se

Fa l se

T r u e

Самостоятельная подготовка

Пересдача зачета

Сдача зачетов больше 3 раз?

Увеличение количества

сдач

T r u e

Fa l se

Подготовка кпересдаче

Количество пересдач больше 3

Подготовкак итоговойаттестации

ДеньсдачиГОСа?

ГОС

ГОСысданы?

Защита диплома

Диплом защищенуспешно

Fa l se

T r u e

T r u e

T r u e

Fa l se Окончаниеобучения

Запись

Выпуск без дипломаОтчисление

Fa l se

T r u eFa l se

Fa l se

T r u e

Продолжение учебного процесса

T r u e

Fa l se

T r u e

Fa l se

Счетчик семестров

A

B

C

D

E

G

F

H

Имитационная модель образовательного процесса УВАУ ГА





МИНИСТЕРСТВО ТРАНСПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

УЛЬЯНОВСКОЕ ВЫСШЕЕ АВИАЦИОННОЕ УЧИЛИЩЕ

ГРАЖДАНСКОЙ АВИАЦИИ (ИНСТИТУТ)

Кафедра управления и экономики на воздушном транспорте

Факультет менеджмента на воздушном транспорте

ОТЧЕТ ПО РАБОТЕ

дисциплина «Исследование систем управления»

Выполнил курсант (студент) группы №

_________________________________

(Ф.И.О., шифр)

Работу принял и проверил

преподаватель ____________________

Ульяновск 200__




Documents

о одичес - ulstu.ruvenec.ulstu.ru/lib/disk/2014/Stepanov_2.pdf · 2014. 11. 26. · Рассмотрены концепции моделирования с помощью ПО