Метод описания процессов IDEF 3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимо­действия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделиро­вании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сот­рудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время. Каждый тенарий сопровождается описанием процесса и может быть использован _я документирования каждой функции.

IDEF3 - это метод, имеющий основной целью дать возможность налитикам описать ситуацию, когда процессы выполняются в определен­ной последовательности, а также описать объекты, участвующие совместно _в одном процессе.

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

IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитацион­ного анализа.

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

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

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

 

 

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозна­чающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточ­няться и редактироваться. Идентификатор работы присваивается ^пРи создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

Работа в IDEF3 требует более подробного описания, чем работа в IDEF0 Каждая UOW должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description). Эта информа­ция заносится во вкладку UOW диалога Activity Properties (рис. 1.4.4).

Рис. 1.4.4. Вкладка UOW диалога Activity Properties Пример значений свойств UOW приведен в табл. 1.4.1.

 

Таблица 1.4.1. Пример текстового описания компонентов UOW

Т un            Использование

NAME        Подготовка компонентов____________________

"Definition  Подготавливаются все компоненты компьютера согласно

___________ спецификации заказа________________________

"Objects       Компоненты: винчестеры, корпуса, материнские платы,

видиокарты, звуковые карты, дисководы CD-ROM

и флоппи, модемы, программное обеспечение___

"Constrains      Установка модема требует установки дополнительного
____________ пограммного обеспечения____________________

Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 1.4.5) диалога Arrow Properties (пункт контекстного меню Style).

 

 

Рис . 1.4.5. Вкладка Style диалога Arrow Properties

Старшая (Precedence) стрелка - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Стрелка отношения (Relational Link) - пунктирная линия, исполь­зующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.

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

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

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

 

Старт работы Окончание работы Старт работы- Окончание

-источника -источника            цели            работы -цели Старшая или

Поток объектов

Старт работы Старт работы- Окончание работы Окончание
-источника    цели             -источника         работы-цели
------ '----------------- '------------------------ '------------------ '------- Отношение

Старт работы Старт работы- °^к°™ние   Окончание работы
-источника    цели                 работы-цели -источника

---- '----------------- '------------------------ '------------------ ^1---------- Отношение

 

Рис. 1.4.6. Временная диаграмма выполнения работ

Перекрестки ( Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветв­лении или для отображения множества событий, которые могут или должны завершены перед началом следующей работы. Различают перекрестки я слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для «ветвления. Для внесения перекрестка служит кнопка Щ (добавить ^диаграмму перекресток - Junction) в палитре инструментов. В диалоге junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.4.2.

Таблица 1.4.2. Типы перекрестков

 

 

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties (вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и раз­ветвляться только через перекрестки. Рис. 1.4.7-1.4.11 иллюстрируют смысл перекрестков каждого типа.

Рис. 1.4.7. Перекрестки для слияния и разветвления типа синхронного

"И". Здесь после завершения работы 1 одновременно запускаются

работы 2 и 4. Для запуска работы 5 требуется одновременное

завершение работ 3 и 4

 

Рис. 1.4.8. Перекрестки для слияния и разветвления типа асинхронного

"И". Здесь после завершения работы 1 запускаются работы 2 и 4

(не обязательно одновременно). Для запуска работы 5 требуется

завершение работ 3 и 4 (не обязательно одновременное)

 

 

 

Рис. 1.4.9. Перекрестки для слияния и разветвления типа асинхронного

"ИЛИ". Здесь после завершения работы 1 запускается либо работа 2,

либо работа 3, либо работа 4, либо их сочетание (не обязательно

одновременно). Для запуска работы 5 требуется завершение любой

из работ 2, 3 и 4 или их сочетания (не обязательно одновременное)

Рис. 1.4.10. Перекрестки для слияния и разветвления типа синхронного

"ИЛИ". Здесь после завершения работы 1 запускается либо работа 2,

либо работа 3, либо работа 4, либо их сочетание. Если запускается

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

работы 5 требуется завершение любой из работ 2, 3 и 4 или их

сочетания. Если завершается более чем одна работа, требуется их

одновременное завершение

Рис. 1.4.11. Перекрестки для слияния и разветвления типа исключающего

"ИЛИ". Здесь после завершения работы 1 запускается только одна

работа - либо работа 3, либо работа 4. Для запуска работы 5 требуется

завершение только одной из работ, 3 или 4

Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и для разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов необходимо соблюдать следующие правила:

1. Каждому перекрестку для слияния должен предшествовать перекресток
для разветвления.

2. Перекресток для слияния "И" не может следовать за перекрестком для
разветвления типа синхронного или асинхронного "ИЛИ" (рис. 1.4.12).
Действительно, после работы 1 может запускаться только одна работа -
2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3.
Такой сценарий не может реализоваться.

Рис. 1.4.12. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

 

3. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ" (рис. 1.4.13).

 

Рис. 1.4.13. Неверное размещение перекрестков. Перекресток для слияния

"И" не может следовать за перекрестком для разветвления типа

исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может сле­довать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запус­ка работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.

 

 

Рис. 1.4.14. Неверное размещение перекрестков. Перекресток для слияния

типа исключающего "ИЛИ" не может следовать за перекрестком

для разветвления типа "И"

4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

 

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.4.15). Для внесения объекта ссылки служит кнопка ШЗ (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямо­угольник работы. Имя объекта ссылки задается в диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддер­живает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объек­тов, не поддерживаются.

 

Рис. 1.4.15. Объект ссылки

 

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

 

Таблица 1.4.3. Типы объектов ссылок

 

 

 

 

Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание вклю­чает все возможные пути развития процесса. Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. По умолчанию при декомпозиции на диаграмму IDEF3 соз­дается описание. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario.

Возможность множественной декомпозиции предъявляет дополни­тельные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, номера декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.4.16).

 

Рис. 1.4.16. Номер единицы работы ( UOW)

Для описания номер декомпозиции равен 1. Для сценария номер деком­позиции всегда больше 1.

При создании сценария или описания необходимо придерживаться дополнительных ограничений - в сценарии или декомпозиции может су­ществовать только одна точка входа. За точкой входа следует работа или перекресток. Для декомпозиции может существовать только одна точка выхода. Сценарий, который не является декомпозицией, может иметь несколько точек выхода.

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

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

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

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

Поскольку разные фрагменты модели IDEF3 могут быть созданы раз­ными группами аналитиков в разное время, IDEF3 поддерживает простую схему нумерации работ в рамках всей модели. Разные аналитики оперируют разными диапазонами номеров, работая при этом независимо. Пример выделения диапазона приведен в табл. 1.4.4.

 

Таблица 1.4.4. Диапазоны номеров работ

 

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

Работы, перекрестки и документирование объектов. IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить инфор­мацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перек­рестков занимает значительное место на диаграмме и использование иерар­хии перекрестков затрудняет расположение работ на диаграмме.

1.4.3. Организационные диаграммы и диаграммы Swim Lane

BPwin 4.0 содержит набор инструментов для моделирования организа­ционной структуры предприятия. В отличие от предыдущей версии 2.5 он содержит четыре новых словаря - словарь изображений (bitmap), словарь ресурсов, словарь ролей и словарь групп ролей. Словарь изображений служит для импорта файлов в формате bmp в модель. Импортированные изображения можно использовать в диаграммах для улучшения их внеш него вида. Для импорта изображения следует перейти в меню Dictionary/ Bitmaps. Появляется диалог Bitmap Dictionary (рис. 1.4.17), в котором сле­дует щелкнуть по кнопке Inport и найти файл формата bmp.

Рис . 1.4.17. Диалог Bitmap Dictionary

 

Словарь Role Group Dictionary (меню Dictionary/Role Group, рис. 1.4.18) позволяет создать и определить свойства групп ролей. Группы ролей могут использоваться как на организационных диаграммах, так и на диаграммах Swim Lane. В качестве значения группы ролей может быть название пред­приятия, отдела, цеха или название региона, города и т. д.

 

 

       Рис. 1.4.18. Словарь групп ролей

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

 

Словарь ролей вызывается из меню Dictionary/Role (рис. 1.4.19).

 

Рис. 1.4.19. Словарь ролей

Ролью может быть должность или позиция конкретного исполнителя. Каждой роли может соответртвовать одна или несколько групп ролей. Кроме того, в словаре ролей для каждой роли можно внести определение (Definition), связать роль с изображением (Bitmap) и геометрической фигурой (Shape), указать важность роли (Importance).

Словарь ресурсов (меню Dictionary/Resource, рис. 1.4.20) позволяет создать ресурс и связать его с комбинацией "группа ролей/роль". Ресурсом для роли может быть конкретный исполнитель. В качестве значения ресурса, например, можно использовать фамилию и имя сотрудника.

 

                                                         Рис. 1.4.20. Словарь ролей

На основе информации, внесенной в словари изображений, групп ролей, ролей и ресурсов, можно создать организационную диаграмму. Организационная диаграмма позволяет документировать и представить в виде дерева структуру организации (например штатное расписание и т. д.). Для создания организационной диаграммы следует выбрать меню Diagram/Add Organization Chart. Появляется гид Organization Chart Wizard. В первом диалоге гида (рис. 1.4.21) следует внести название и имя автора диаграммы, группу ролей и роль для верхнего уровня иерархического дерева.

            Рис . 1.4.21. Первый диалог гида Organization Chart Wizard

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

Рис. 1.4.22. Создание второго уровня организационной диаграммы в Organization Chart Wizard

Третий диалог Organization Chart Wizard предназначен для изменения свойств организационной диаграммы. В группе Drawing можно указать, какая именно информация будет отображаться на блоках диаграммы (наименование блока, имя группы ролей, роль и ресурс). Для отображения иконок на диаграмме в группе Draw Style следует выбрать опцию Bitmap.

После щелчка по кнопке Finish создается организационная диаграмма (рис. 1.4.23).

 

Рис. 1.4.23. Первый и второй уровни организационной диаграммы

 

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

■ Edit subordinate list — редактирование блока;

■ Add subordinates - добавляет нижний уровень;

■ Add sibling on left - добавляет блок на текущий уровень слева от редак­
тируемого блока;

■ Add sibling on rigth - добавляет блок на текущий уровень справа
от редактируемого блока.

Созданные в словаре Role Dictionary роли могут быть также исполь­зованы в диаграмме Swim Lane. Диаграмма Swim Lane является разно­видностью диаграммы IDEF3, позволяющей явно описать роли и ответственности исполнителей в конкретной технологической операции. Эта диаграмма разделена на горизонтальные полосы, с каждой полосой может быть связана роль или UDP типа Text List. Полоса может содержать объекты диаграммы 1DEF3 (UOW, перекрестки и объекты ссылок), относящиеся к соответствующей роли.

Для создания диаграммы Swim Lane следует выбрать меню Diagram/Add Swim Lane diagram. Появляется гид Swim Lane diagram Wizard. В первом диалоге гида (рис. 1.4.24) следует внести название и имя автора диаграммы, выбрать имя и номер диаграммы IDEF3, на основе которой будет построена диаграмма, и группу ролей, из которой можно будет выбрать роли, связанные с диаграммой.

         Рис. 1.4.24. Первый диалог гида Swim Lane Diagram Wizard

Во втором диалоге гида следует выбрать роли, на основе которых будет создана диаграмма. Диаграмма будет разделена на количество полос, указанных в колонке Display Swim Line.

Рис. 1.4.25. Выбор ролей во втором диалоге гида Swim Lane Diagram Wizard

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

Рис. 1.4.26. Диаграмма Swim Lane

1.4.4. Использование нетрадиционного синтаксиса на диаграммах функциональной модели

BPwin 4.0 позволяет нарушить традиционный синтаксис нотаций IDEFO, IDEF3 и DFD и использовать для работы не прямоугольники, а практически любые геометрические фигуры. Кроме того, можно разместить на работе изображение, импортированное в словарь Bitmap Dictionary. Для использования нетрадиционного синтаксиса необходимо щелкнуть по работе и выбрать в контекстном меню пункт Box Style. Во вкладке Box Style (рис. 1.4.27) следует выбрать опцию Custom и ука­зать геометрическую фигуру (Shape) и изображение (Bitmap).

 

Рис . 1.4.27. Вкладка Box Style диалога Activity Properties

После щелчка по кнопке ОК на диаграмме работа отображается в нетрадиционном синтаксисе (рис. 1.4.28).

Рис. 1.4.28. Отображение работы в виде овала на диаграмме IDEF0

Использование нетрадиционного синтаксиса может быть полезно при решении ряда задач, например при преобразовании диаграммы IDEF3 в имитационную модель Arena (рис. 1.4.29, см. также 1.4.6).

Рис. 1.4.29. Диаграмма 1 DEF3, выполненная в синтаксисе имитационной модели Arena

1.4.5. Создание смешанной модели

В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия (рис. 1.4.30). Иерархию работ в смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEF0 изображаются зеленым цветом, IDEF3 - желтым, DFD -синим.

Авторы нотаций IDEFO, IDEF3 и DFD не предполагали совместного использования диаграмм различной нотации в одной модели, поэтому создание смешанной модели имеет ряд особенностей. Во-первых, сущест­вуют определенные правила декомпозиции работы одной нотации в диаг­рамму другой. Во-вторых, BPwin позволяет разместить объекты одной нота­ции на диаграмме другой. Рассмотрим эти особенности.

 

Рис. 1.4.30. Представление смешанной модели в окне Model Explorer

BPwin допускает следующие переходы с одной нотации на другую:

■ IDEF0 -> DFD;

■ IDEF0 -> IDEF3;

■ DFD -> IDEF3.

Декомпозировать работу DFD на диаграмму IDEF0 нельзя, так же как декомпозировать работу IDEF3 на диаграмму любой другой нотации.

Декомпозиция работы IDEF0 в диаграмму DFD. Для создания дочерней диаграммы DFD следует при декомпозиции в диалоге Activity Box Count (см. рис. 1.2.5) выбрать радиокнопку DFD. Создается новая диаграм­ма DFD, и стрелки, которые касаются родительской работы, мигрируют на диаграмму нижнего уровня так, как если бы это была диаграмма IDEF0 (рис. 1.4.31 и 1.4.32).

I

Рис. 1.4.31. Декомпозируемая работа на диаграмме IDEF0

Стрелки входа родительской работы на дочерней диаграмме DFD показываются входящими стрелками с левой стороны диаграммы DFD, стрелки управления - входящими стрелками с верхней стороны диаграммы и т. д. Хотя нотация DFD не включает понятия "управление" и "механизм" и можно создавать внутренние стрелки исходящими из любой грани работы и входящими в любую грань, BPwin не позволяет связать граничные стрелки на диаграмме DFD произвольным образом. Стрелки можно связать только так, как если бы это была диаграмма IDEF0, т. е. входящую с верх­ней грани диаграммы стрелку - только к верхней грани работы и т. д.

 

 

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

1) удалить все граничные стрелки на диаграмме DFD;

2) создать соответствующие внешние сущности и хранилища данных;

Рис. 1.4.33. Тоннелирование стрелок на диаграмме IDEF0

3) создать внутренние стрелки, начинающиеся с внешних сущностей
вместо граничных стрелок;

4) стрелки на диаграмме IDEF0 затоннелировать.

Результат этих действий представлен на рис. 1.4.33 и 1.4.34.

Рис. 1.4.34. Замена граничных стрелок внутренними на диаграмме DFD

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

 

 

                                                                                                                                        

 

Межстраничные ссылки (Off-Page Reference) и внешние сущности (External Reference) на диаграммах DFD и IDEF0. Нотация DFD включает межстраничные ссылки - инструмент, позволяющий описать переход стрелки (т. е. передачу данных или объектов) с одной диаграммы на другую. Для создания межстраничной ссылки на диаграмме DFD следует создать новую граничную стрелку. У границы диаграммы эта стрелка будет помече­на квадратными скобками, так же как неразрешенная стрелка на диаграмме IDEF0. Затем следует щелкнуть правой кнопкой мыши по квадратным скобкам и выбрать в контекстном меню пункт Off-Page Reference.

Появляется диалог Off-Page Arrow Reference (рис. 1.4.35). В нем необ­ходимо указать диаграмму, на которую будет направлена стрелка, и, если это диаграмма в нотации IDEF0, границу, от которой будет исходить стрелка (Destination border).

Рис. 1.4.35. Создание межстраничной ссылки на диаграмме DFD

В результате будет создана межстраничная ссылка (см., например, ссылку на диаграмму А23 на рис. 1.4.34) как на диаграмме-источнике, так и на диаграмме-назначении. Межстраничная ссылка может быть помечена как C-number диаграммы, как номер диаграммы по узлу (как на рис. 1.4.34) или как имя диаграммы. Для изменения метки следует перейти

 

в меню Model/Model Properties и во вкладке Display диалога Model Properties и в группе Off-Page Reference label выбрать нужную опцию.

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

Для создания внешней сущности на диаграмме DFD следует создать новую граничную стрелку. У границы диаграммы эта стрелка будет поме­чена квадратными скобками. Затем следует щелкнуть правой кнопкой мыши по квадратным скобкам и выбрать в контекстном меню пункт External Reference. В диалоге External Reference следует выбрать или внести имя внешней сущности.

На диаграмме DFD можно также создать тоннельную стрелку, хотя нотация DFD не предусматривает создания такого элемента. Для этого сле­дует щелкнуть правой кнопкой мыши по квадратным скобкам и выбрать в контекстном меню пункт Arrow Tunnel.

В результате BPwin позволяет создавать на диаграмме DFD четыре типа граничных стрелок (рис. 1.4.36, сверху вниз):

■ обычная граничная стрелка (не допускается нотацией DFD);

■ межстраничная ссылка;

■ тоннельная стрелка (не предусмотрена нотацией DFD);

■ внешняя ссылка.

Рис. 1.4.36. Граничные стрелки на диаграмме DFD

Интересной особенностью BPwin является то, что те же самые типы стрелок можно создать на диаграмме IDEF0 (рис. 1.4.37):

■ обычная граничная стрелка;

■ межстраничная ссылка (не предусмотрена нотацией 1DEF0);

■ тоннельная стрелка;

■ внешняя ссылка (не предусмотрена нотацией IDEF0).

 

Рис. 1.4.37. Граничные стрелки на диаграмме IDEF0

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

Декомпозиция работы IDEF0 или DFD в диаграмму IDEF3. Стрелки на диаграммах IDEF0 и DFD означают потоки информации или объектов, передаваемых от одной работы к другой. На диаграммах IDEF3 стрелки мо­гут показывать только последовательность выполнения работ, т. е. имеют иной смысл, нежели стрелки IDEF0 и DFD. Поэтому при декомпозиции ра­боты IDEF0 или DFD в диаграмму IDEF3 стрелки не мигрируют на нижний уровень. Если необходимо показать на дочерней диаграмме IDEF3 (рис. 1.4.38) те же объекты, что и на родительских диаграммах IDEF0 (рис. 1.4.39) или DFD, необходимо использовать объекты ссылки (referent).

Рис. 1.4.38. Фрагмент дочерней диаграммы 1 DEF3

Рис. 1.4.39. Фрагмент родительской диаграммы IDEFO

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

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

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

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

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

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

        Рис. 1.4.40. Простейшая имитационная модель

 

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

Рис. 1.4.41. Палитра инструментов Arena

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

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

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

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

            Рис. 1.4.42. Отчет по результатам проигрывания модели

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

 

Рис. 1.4.43. Модель обработки документа

 

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

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

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

Рис. 1.4.44. Диаграмма IDEF 3 - пример для иллюстрации экспорта в Arena

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

 

 

Рис. 1.4.45. Имитационная модель Arena -результат импорта из BPwin

 

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

Рис. 1.4.46. Диалог Resource для редактирования ресурсов объектов имитационной модели Arena

 

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

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

Основным расширением функциональности Service Pack 2 для BPwin явилось включение обучающего модуля (On-line tutorial). Для вызова обучающей программы в BPwin следует перейти в меню Help/BPwin online Tutorial. Появляется диалог BPwin Tutorial (рис. 1.5.1), в котором можно выбрать один из 10 уроков.

Рис. 1.5.1. Диалог BPwin Tutorial

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

           

 

                                                                                                                                             

Рис. 1.5.2. Обучение построению смешанных моделей в BPwin Tutorial

 

               Рис. 1.5.3. Обучение технике создания внутренних стрелок

 

Глава 2

Создание отчетов

2.1. Создание отчетов в BPwin

2.1.1. Встроенные шаблоны отчетов

Существует три способа создания отчетов в BPwin 4.0:

1) с помощью встроенных шаблонов;

2) с помощью Report Template Builder;

3) с помощью RPTwin.

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

Отчеты на основе встроенных шаблонов можно создать, выбрав из меню Tools/Reports необходимый тип шаблона. Всего имеется семь типов шаблонов отчетов:

1. Model Report. Этот отчет уже упоминался в 1.2.1. Он включает инфор­
мацию о контексте модели - имя модели, точку зрения, область, цель,
имя автора, дату создания и др.

2. Diagram Report. Отчет по конкретной диаграмме. Включает список
объектов: работ, стрелок, хранилищ данных, внешних ссылок и т. д.

3. Diagram Object Report. Наиболее полный отчет по модели. Может
включать полный список объектов модели: работ, стрелок с указанием
их типа и др. - и свойства, определяемые пользователем.

4. Activity Cost Report. Отчет о результатах стоимостного анализа. Будет
рассмотрен ниже.

5. Arrow Report. Отчет по стрелкам. Может содержать информацию
из словаря стрелок, информацию о работе-источнике, работе-назначении
стрелки и информацию о разветвлении и слиянии стрелок.

6. DataUsage Report. Отчет о результатах связывания модели процессов
и модели данных. (Будет рассмотрен ниже.)

7. Model Consistency Report. Отчет, содержащий список синтаксических
ошибок модели.

Синтаксические ошибки IDEF0 с точки зрения BPwin разделяются на три типа:

 

■ первых, это ошибки, которые BPwin выявить не в состоянии.
Например, синтаксис IDEF0 требует, чтобы имя работы было
выражено отглагольным существительным ("Изготовление изде­
лия", "Обслуживание клиента", "Выписка счета" и т. д.), а имя
стрелки также должно быть выражено существительным. BPwin
не позволяет анализировать синтаксис естественного языка (английс­
кого и русского) и смысл имен объектов и поэтому игнорирует ошиб­
ки этого типа. Выявление таких ошибок - ручная работа, которая
ложится на плечи аналитиков и должна контролироваться руководи­
телем проекта.

■ Ошибки второго типа BPwin просто не допускает. Например, каждая
грань работы предназначена для определенного типа стрелок. BPwin
просто не позволит создать на диаграмме IDEF0 внутреннюю
стрелку, выходящую из левой грани работы и входящую в правую
грань.

■ Третий тип ошибок BPwin позволяет допустить, но детектирует их.
Полный их список можно получить в отчете Model Consistency
Report. Список ошибок может содержать, например, неименованные
работы и стрелки (unnamed arrow, unnamed activity), несвязанные
стрелки (unconnected border arrow), неразрешенные стрелки
(unresolved (square tunneled) arrow connections) и т. д. Пример отчета
Model Consistency Report приведен на рис. 2.1.1.

 

                      Рис . 2.1.1. Отчет Model Consistency Report

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Для каждого из семи типов отчетов он выглядит по-своему. Рассмотрим типичный диалог Arrow Report (рис. 2.1.2).

Рис. 2.1.2. Диалог Arrow Report

 

Раскрывающийся список Standart Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет - это запоминаемая комби­нация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение - свойства, определяемые пользователем (User-Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из "родной" модели. Стандартный отчет можно изменить (кнопка Update) или удалить (кнопка Delete).

В правом верхнем углу диалога находится группа управляющих элементов для выбора формата отчета. Доступны следующие форматы:

■ Labeled - отчеты включают метку поля, затем, в следующей строке,
печатается содержимое поля;

■ Fixed Column - каждое поле печатается в собственной колонке;

■ Tab-Comma Delimited - каждое поле печатается в собственной
колонке. Колонки разделяются знаком табуляции или запятыми;

■ DDE Table - данные передаются по протоколу DDE в приложение,
например в MS Word или Excel;

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

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

Опция Multi-Valued Format регулирует вывод полей в отчете при груп­пировке данных:

■ Repeating Group - детальные данные объединяются в одно поле,
между значениями вставляется +.

■ Filled — дублирование данных для каждого заголовка группы;

■ Header (опция по умолчанию) - печатается заголовок группы, затем -
детальная информация.

---

Дата добавления: 2019-07-17; просмотров: 1805; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!