Разработка IDEF0 модели в AllFusion Process Modeler

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

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

· декомпозиции – отражает более детальное описание отдельной части бизнес-процесса;

· дерева узлов – описывает иерархическую зависимость работ;

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

Основными элементами модели IDEF0 являются: функциональный блок и стрелка.

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

Для каждого функционального блока в рамках модели определяется:

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

· название, которое должно отражать действие, оно задается только в виде глагола или отглагольного существительного, например, ИЗГОТОВИТЬ ДЕТАЛЬ, СОБРАТЬ ДАННЫЕ, ИЗГОТОВление детели, сбор данных;

· описание, которое дает развернутую смысловую характеристику действия. Например, сбор данных по телефону, сбор данных по электронной почте, проведение опроса и др.

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

Рис.1. Пример контекстной диаграммы

Для того чтобы задать другие свойства блока необходимо нажать правой клавишей мыши на изображении блока и выбрать нужное свойство Activity properties (рис. 2). Для каждого действия необходимо задать его имя (Name) и описание (Definition). Разработка модели начинается с определения контекстной диаграммы, в которой определяется взаимодействие модели с внешними компонентами (рис. 1).

Рис. 2. Редактор задания свойств действия.

Второй основной элемент IDEFO-методологии — это стрелка. Стрелка бывает четырех типов: стрелка-вход, выход, механизм и управление.

1. Вход (Input) рисуется, как входящая в левую грань функционального блока. Вход показывает, что требуется для выполнения функции, например: КЛИЕНТ.

2. Выход (Output) – исходящая из правой грани блока. Выход — результат функции, например: Реализованная услуга

3. Механизм (Mechanism) входящая в нижнюю грань стрелка. Механизм с помощью чего или кого выполняется функция, например: Персонал

4. Управление (Control) рисуется входящей в верхнюю грань блока. Управление ограничивает (регламентирует) выполнение функции, например, ПРАВИЛА, ЛИЦЕНЗИЯ.

Каждая стрелка (рис.3) определяется уникальным именем (Name), которое задается существительным в единственном числе им. падеже, и описанием (Definition, Note) (рис. 4). Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 3. Задание имени стрелки.

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

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

Рис. 4. Задание свойств Definition и Note

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

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

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

Рис. 5. Туннельная стрелка

Для их «перетаскивания» наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и выбрать из выпадающего меню Arrow Tunnel. Появится диалоговое окно Border Arrow Editor (рис. 6).

Рис. 6. Диалог Border Arrow Editor

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

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

Рис. 7. Декомпозиция диаграммы процесса

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

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

Назначение процесса аналогично процессу в модели IDEF0. В этой модели применяются специальные элементы: хранилище данных и внешняя сущность.

Хранилище данных (Data Store) позволяет определять данные, которые будут сохраняться в памяти между процессами. Информация, которую оно содержит, можно использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Для того чтобы добавить хранилище данных в модель необходимо выделить элемент панели инструментов и поместить его в поле модели.

Внешняя сущность представляет собой внешний источник или получатель данных. Ее имя должно содержать существительное, например, "клиент". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. На панели инструментов внешняя сущность задана пиктограммой . Пример DFD диаграммы приведен на рис.8.

Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком. Таблица событий включает в себя наименование внешней сущности, событие, его тип (типичный для системы или исключительный, реализующийся при определенных условиях) и реакцию системы. После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость. Полнота диаграммы обеспечивается, если в системе нет "повисших" процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены.

Рис. 8. Диаграмма потока данных