Описание метода IDEF0

История возникновения стандарта IDEF0

IDEF0, как стандарт, был разработан в 1981 году департаментом Военно-Воздушных Сил США в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Набор стандартов IDEF унаследовал свое название от этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик-специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандартам и Технологиям США (NIST).

IDEF1 (Information Modeling) — одна из методологий семейства IDEF. Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды.

Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X–диаграммы используются рядом распространённых CASE–средств (в частности, ERwin, Design/IDEF).

IDEF3 англ. Integrated DEFinition for Process Description Capture Method — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие^[1]

Применение

IDEF3 широко применяется при разработке информационных систем. При этом используется инструмент визуального моделирования бизнес-процессов

[править] Описание

[править] Два типа диаграмм в IDEF3

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

IDEF3 состоит из двух методов. Process Flow Description (PFD) — Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса. Object State Transition Description (OSTD) — описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

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

• диаграмму Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD)
• диаграмму Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN)

[править] Компоненты диаграммы описания процесса

Диаграмма IDEF3 Process Flow Description может состоять из 4 основных описательных блоков:

• работы (boxes, activities)
• стрелки или связи (arrows, links)
• перекрёстки (junctions)
• объекты ссылок
• Unit of Behavior
• Decomposition
• Elaboration

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (к слову сказать, он активно применяется и в российских госструктурах, например в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF (и предшествующей методолoгии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес-процесс реинжиниринг).

[править] Семейство стандартов

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

• IDEF0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);

• IDEF1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

• IDEF1X (IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

• IDEF2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьёзными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

• IDEF3 — Process Description Capture — Документирование технологических процессов,

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

• IDEF4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

• IDEF5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

• IDEF6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

• IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

• IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

• IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

• IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

• IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

• IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

• IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

Описание метода IDEF0

Основным рабочим элементом при создании модели IDEF0 является диаграмма.

Каждая диаграмма содержит функциональные блоки и интерфейсные дуги (см. рис1).

Блоки (прямоугольники) обозначают функции системы. Названия блоков – это глаголы или глагольные обороты. Например: сделать деталь, обработать заказ, выписать квитанцию.

Каждая сторона блока имеет свое значение (см. рис. 1):

• левая - вход;
• правая - выход;
• верхняя - управление;
• нижняя - механизм.

Рис. 1. Функциональный блок

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

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

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

Диаграммы в IDEF0 строятся по принципу декомпозиции.

Первая диаграмма, которая называется контекстной (на чертеже обозначается A-0) содержит всего один функциональный блок, который представляет систему как единое целое. Контекстная диаграмма обязательно содержит цель и точку зрения. Цель – это список вопросов, на которые должна отвечать разрабатываемая система, то есть краткое описание системы, точка зрения – это контекст, в котором рассматривается система.

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

Рис. 2. Принцип декомпозиции при построении IDEF0 модели

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

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

Рис.3. Туннелирование

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

Поиск по сайту: