Наличие в диаграммах DFD элементов для обозначения источников , приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов . Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе .
BPMN 2.0, EPC, IDEF — описание бизнес процессов от А до Я // Что выбрать и почему CORE лучше?
Техника описания набора данных IDEF3 является частью структурного анализа . В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
IDEF3 может быть также использован как метод создания процессов . IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть документирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо документировать цель модели — те вопросы, на которые призвана ответить модель.
Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
Единицы работы — Unit of Work (UOW) — также называемые работами ( activity ), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер ( идентификатор ); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, «Изготовление изделия»). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ . Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.
Построение диаграммы IDEF0 в process modeler (bpwin)
Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи , стиль которых устанавливается через меню Edit/Arrow Style :
Старшая (Precedence)
сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Отношения (Relational Link)
пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow)
стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект , необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект , изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект . Поток объектов имеет ту же семантику, что и старшая стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ — работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.
Окончание одной работы может служить сигналом к началу нескольких работ , или же одна работа для своего запуска может ожидать окончания нескольких работ . Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния ( Fan -in Junction ) и разветвления стрелок ( Fan -out Junction ). Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка
— (добавить в диаграмму перекресток — Junction ) в палитре инструментов. В диалоге Select Junction Type необходимо указать тип перекрестка .
Смысл каждого типа приведен в таблице 8.1.
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties, который вызывается в контекстном меню перекрестка командой Definition/Note. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки .
Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка
— (добавить в диаграмму объект ссылки — Referent ) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы
. Имя объекта ссылки задается в диалоге Referent ( пункт Name контекстного меню ), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные ( unconditional ), синхронные (synchronous) и асинхронные ( asynchronous ). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
Источник: intuit.ru
Лабораторная работа №2
Цель работы : освоить методологию IDEF3 для создания бизнес-процессов.
Теоретическая справка
В процессе эксплуатации модели IDEF 0 выяснилось множество недостатков этой модели, сужающих область её применения. Функциональная направленность моделей IDEF 0 затрудняла или не позволяла вообще указать некоторые аспекты работы нескольких бизнес-процессов, например, показать их взаимосвязь, синхронность исполнения и т.п. Кроме того, жёсткие условия, накладываемые на расположение дуг в зависимости от их направления в блок активности, делали трудоёмким создание диаграмм и делали их менее наглядными. Поэтому была создана новая спецификация семейства стандартов IDEF – IDEF 3.
IDEF 3 – графический язык описания функциональных систем, позволяющий описать последовательность выполнения работ направленных на преобразование или обработку какого-либо объекта, а так же их временную взаимосвязь и взаимозависимость. Представление бизнес-процессов в виде последовательности работ относит IDEF 3 к диаграммам класса Workflow Diagram (дословно – «диаграммы потоков работ» с англ.), предназначенных для описания потоков процессов или работ.
Стандартом IDEF 3 предусматривается два типа диаграмм – диаграммы описания последовательности этапов процесса (« Process Flow Description Diagram » или « PFDD ») и диаграммы состояния объекта и трансформации в процессе (« Object State Transition Network » или « OSTN ») (смотрите рисунки 1 и 2).
Рисунок 1 — PFDD- диаграмма IDEF3 .
Рисунок 2 — OSTN -диаграмма IDEF 3.
Среда BPWin использует только PFDD -нотацию, поэтому дальнейший материал касается только нотации PFDD .
В основе методологии IDEF 3 лежат следующие правила и понятия:
— Unit of Work ( UOW ) (дословно – «единица работы» с англ.) или Activity («работа» в терминах методологии) – показывают некоторое действие; обозначаются некоторым именем, выраженным глаголом или существительным отглагольного наклонения (например, «выдать документацию» или «выдача документации», но не «выданные документы») и поясняющим их суть; являются главными элементами диаграммы и изображаются в виде прямоугольников с прямыми углами; по смыслу схожи с блоками активности в IDEF 0;
— Связи – показывают взаимоотношения работ и изображаются в виде однонаправленных стрелок; в отличие от IDEF 0 связи могут иметь произвольное направление входа и выхода, но рекомендуется строить диаграммы таким образом, чтобы связи были направлены слева направо; подписываются названием, характеризующим результаты работы или входные данные для работы, название выражается существительным (например, «построенный дом»);
— в IDEF 3 различают три типа связей – старшая (« Precedence »), отношения (« Relation Link »), потоки объектов (« Object Flow »); тип связей в IDEF 3 не зависит от направления входа или выхода из блока UOW ;
— Старшая – показывает, что работа-источник должна завершиться ранее, чем начнётся работа-цель; обозначается в виде стрелки со сплошной линией; рисуется слева направо или сверху вниз;
— Отношения – показывает связь между работами; обозначается в виде стрелки с пунктирной линией;
— Поток объектов – показывает, что объект создаётся в некоторой работе и затем неоднократно – в двух или более единицах работа – используется;
— Перекрёстки (« Junction ») – это особые элементы свойственные нотации IDEF 3, которые позволяют указать взаимозависимость нескольких работ; различают перекрёстки слияния (« Fan — in Junction » ) и перекрёстки разветвления (« Fan — out Junction » ); перекрёсток не может использоваться одновременно слияния и разветвления; каждый из перекрёстков получает индивидуальный номер;
Таблица 1 — Типы перекрёстков
Обозначение на диаграмме
Источник: znanio.ru
Глава 2. Создание модели процессов в BPWin
CASE‑средство BPWin фирмы Computer Associates поддерживает методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram – потоки работ), DFD (DataFlow Diagram – потоки данных).
В функциональной модели информационная система (контекстная диаграмма) разбивается на подсистемы (диаграммы декомпозиции), и каждая подсистема разбивается на более мелкие и так далее до достижения необходимой степени подробности. После каждого сеанса декомпозиции производится анализ диаграмм декомпозиции разработчиками и заказчиком. На основе полученной модели можно построить модель базы данных средствами ERWin (фирма Computer Associates). Информация о проекте находится в хранилище моделей (Model Mart) c СУБД Sybase, Microsoft SQL Server, Oracle.
Среда разработки
![]() |
Для запуска выполните команду Пуск/Программы/Computer Associates BPWin 4.0/BPWin 4.0,и появится окно среды разработки (рисунок 2.1.1).
Рисунок 2.1.1. Главное окно среды разработки модели BPWin
Окно содержит меню, основную панель инструментов (кнопки создания, открытия, сохранения и распечатки модели, выбора масштаба, масштабирования, проверки правописания, включения/выключения навигатора и дополнительной панели инструментов соответственно), палитру инструментов, навигатор модели в левой части окна c кнопкой двойного действия Diagrams/Activities (диаграммы декомпозици/работы), окно модели, граничные рамки (каркас диаграммы) (рисунок 2.1.1).
Поля заголовка каркаса
Used At – имя родительской диаграммы, если на диаграмму ссылались стрелками вызова.
Author, Date, Rev, Project – имя разработчика, даты создания и последнего редактирования, имя проекта cоответственно.
Notes 1 2 3 4 5 6 7 8 9 10 – число замечаний эксперта на бумажной копии диаграммы (зачеркиваются ненужные цифры).
Status – стадия создания диаграммы (Working, Draft, Recommended, Publication).
Working – новая или сильно измененная диаграмма.
Draft – диаграмма прошла первичную экспертизу.
Recommended – диаграмма прошла все экспертизы.
Publication – окончательный вариант диаграммы.
Reader, Date – имя эксперта (пользователя, заказчика), дата экспертизы.
Context – схема расположения работ верхнего уровня (родительская работа выделена черным цветом).
Поля подножия каркаса
Node, Title – номер родительской работы, имя диаграммы.
Number, Page – номер версии диаграммы (C-Number) и страницы.
Значения полей задаются командой Diagram/Diagram Properties.
Модель рассматривается как совокупность работ с некоторым набором данных. Работы и данные изображаются в модели в виде прямоугольников и стрелочек соответственно. Для каждого объекта модели имеется контекстное меню.
Установка цвета и шрифта реализуется командами Font и Color, а шрифты по умолчанию устанавливаются командой Model/Default Fonts. При создании модели появляется окно с вариантами выбора модели (IDEF0, DEF3, DFD), с полем для ввода имени модели (Name) и вариантами создания: создается заново (Create model), открывается из файла (Open model) или репозитария (Open model from ModeMart).
Функциональная модель (IDEF0)
Принципы построения модели
Моделирование начинается с определения контекста – описания системы в целом (субъекта, целей и точки зрения на модель), т.е. области моделирования (Scope). Под широтой области моделирования понимается граница: что будет рассматриваться внутри системы, а что снаружи. Глубина модели определяет уровень детализации модели.
Цель моделирования(Purpose) заключается в получении ответов на вопросы: почему процесс должен быть замоделирован; что модель должна показывать; что может получить пользователь этой модели?
Точка зрения (Viewpoint) – единое представление о системе с позиции разработчика модели.
![]() |
Для внесения информации о модели используется окно свойств (рисунок 2.2.1.1), вызываемое командой Model/Model Properties.
Рисунок 2.2.1.1. Окно свойств модели
Рассмотрим основные страницы окна свойств модели.
General – имя проекта, фамилии разработчиков, временные рамки модели AS‑IS (как есть) и TO‑BE (как будет).
Purpose – цель и точка зрения.
Definition – определение модели и области.
Source – источники информации для построения модели (опрос, документация и др.)
Status – статус модели (черновой, рабочий, окончательный и т.д.), время создания и редактирования.
Модель AS‑IS отражает существующую организацию работ с цель выявления недостатков (неуправляемые и дублирующие работы, неэффективный документооборот, нерационально используемые информация и объекты и т.п.).
Модель TO‑BE отражает новую организацию бизнес-процессов и исправляет недостатки модели AS‑IS. При большом различии этих моделей может быть создана промежуточная модель, описывающая процесс перехода от начального к конечному состоянию системы.
![]() | ![]() |
Проектирование ИС предполагает создание моделей AS‑IS и TO‑BE, на основе которых строится модель данных, прототип и окончательный вариант ИС. Описание модели получается командой Tools/Reports/Model Report (рисунок 2.1.1.2).
Рисунок 2.1.1.2. Отчет по модели
Диаграммы IDEF0 используются для графического описания бизнес-процессов в виде дерева диаграмм.
Модель может содержать четыре типа диаграмм.
· Контекстная диаграмма является корневой в дереве диаграмм и содержит общее описание системы и ее взаимодействие с внешней средой (рисунок 2.2.3.3).
· Диаграммы декомпозиции являются результатом деления контекстной диаграммы или родительской диаграммы декомпозиции предыдущего уровня.
· Диаграммы дерева узлов показывают иерархическую зависимость работ, но не взаимосвязи между работами.
· Диаграммы для экспозиции (FEO) иллюстрируют отдельные фрагменты модели.
Работы
Работами (Active) называют поименованные отглагольными существительными процессы, функции или задачи, которые выполняются в системе и имеют результаты. Работа оформляется в виде прямоугольника. Управляющая информация входит в прямоугольник сверху, входная информация – слева, а результаты – справа. Механизм (человек, автоматизированная система), выполняющий работу, показывается снизу (п. 2.2.3).
Кнопкой New Model создаются новая модель и ее контекстная диаграмма. Редактор задания свойств работы вызывается командой контекстного меню Definition/Note (рисунок 2.2.2.1).
Кнопкой Go to Child Diagram создается или осуществляется переход на диаграмму декомпозиции (дочерняя работа). Укажите вариант нотации новой диаграммы и число работ в ней (рисунок 2.2.2.2).
Кнопкой Activity Box Toll можно разместить новую работу на свободном месте диаграммы.
Рисунок 2.2.2.1. Окно свойств работы Рисунок 2.2.2.2. Окно Activity Box
Работы располагают по диагонали от левого верхнего угла к правому нижнему (такой порядок называется порядком доминирования). В левом верхнем углу располагается самая важная работа или работа, выполняемая первой. Далее, вправо вниз, располагаются менее важные работы или выполняемые позже. Каждая может быть, в свою очередь, декомпозирована (в левом верхнем углу у работы указывается диагональная черточка). Работы нумеруются автоматически слева направо.
Стрелки
Стрелки (Arrow) показывают взаимодействие работ с внешней средой и именуются существительными.
Существуют следующие типы стрелок.
· Вход (Input) – материал или информация, используемые для получения результата. (Сырье). Эти стрелки входят в левую грань работы.
· Управление (Control) – правила, процедуры, которыми руководствуется работа (задание, чертеж). Стрелки входят в верхнюю грань работы.
· Выход (Output) – материал или информация, производимые работой (готовое изделие). Стрелки исходят из левой грани работы.
· Механизм (Mechanism) – ресурсы, выполняющие работу (персонал предприятия). Стрелки входят в нижнюю грань работы.
· Вызов (Call) – указывает на другую модель работы, которая выполняется за пределами текущей системы. Стрелки исходят из нижней грани.
· Граничные стрелки – показывают взаимодействие контекстной диаграммы с внешней средой. Стрелки могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот.
Порядок размещения стрелок
1. Щелкнуть на кнопке Precedence Arrow Tool (установление режима рисования стрелок) и перенести маркер мышки к месту, откуда должна выходить стрелка (это место выделяется черным цветом) и щелкнуть мышкой.
2. Перенести маркер мышки к месту окончания стрелки (это место выделяется черным цветом) и щелкнуть мышкой.
3. Щелкнуть на кнопке Pointer Tool.
4. Щелкнуть правой кнопкой мыши на линии стрелки и выбрать команду Name (или щелкнуть дважды). Появится окно свойств стрелок (рисунок 2.2.3.1).
5.
![]() |
Ввести наименование стрелки на странице Name этого окна.
Рисунок 2.2.3.1. Окно свойств стрелок
Имена стрелок автоматически заносятся в словарь стрелок (Arrow Dictionary). Этот словарь корректируется редактором, вызываемым командой Model/Arrow Editor (рисунок 2.2.3.2).
ICOM (аббревиатура от Input, Control, Output и Mechanism) – коды, идентифицирующие типы граничных стрелок (границы диаграмм декомпозиции). ICOM‑код содержит обозначение типа стрелки (I, C, O, M) и порядковый номер (C1). Эти коды отображаются автоматически, если включена опция Model/Model Properties/Display/ICOM codes (рисунок 2.2.3.4).
![]() |
Рисунок 2.2.3.2. Окно редактора стрелок
Содержимое словаря стрелок может быть распечатано командой Tools/Reports/Arrow Report.
Несвязанные граничные стрелки (Unconnected borderarrow) появляются автоматически при декомпозиции работы и состоят из всех входных и выходных стрелок (кроме стрелок вызова) декомпозируемой работы.
Для связывания стрелок входа, управления или механизма нужно щелкнуть по наконечнику стрелки и дорисовать стрелку. Для связывания стрелки выхода нужно щелкнуть по началу стрелки и дорисовать ее.
Внутренние стрелки показывают связь между работами (рисунок 2.1.1).
Существуют пять типов связей:
· связь по входу (Output‑Input) – стрелка-выхода из вышестоящей работы на вход нижестоящей (связь «Детали»);
· связь по управлению (Output‑Control) – стрелка-выход из вышестоящей работы на управление нижестоящей (связь «Чертеж»);
· связь выход‑механизм (Output‑Mechanism) – стрелка-выход одной работы на механизм другой;
· обратная связь по входу (Output‑Input feedback) – стрелка-выход нижестоящей работы на вход вышестоящей (связь «Брак»);
· обратная связь по управлению (Output‑Control feedback) – стрелка-выход нижестоящей работы на управление вышестоящей («Рекомендации»).
Явные стрелки имеют источником и назначением единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же объекты, порожденные одной работой, могут использоваться одновременно в нескольких других работах (разветвление). Стрелки, порожденные в разных работах, могут представлять собой однородные объекты (слияние). Cмысл этих стрелок передается наименованиями каждой ветви стрелок. Имя стрелки разветвления может быть уточнено с помощью нового имени ветви, указанного после точки разветвления или слияния соответственно.
Для разветвления стрелки нужно в режиме рисования (нажать кнопку Precedence Arrow Tool) щелкнуть по стрелке и по соответствующему сегменту работы. Для слияния двух стрелок следует в режиме рисования стрелки щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки. Для именования отдельной ветви нужно ее выделить, вызвать редактор имени стрелки и присвоить ей имя.
Тоннелирование стрелок. Граничные стрелки на диаграммах нижнего уровня изображаются в квадратных скобках.
Источник: cyberpedia.su