Методология стандарта IDEF0


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

Методологию IDEF0 можно считать конечным этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique).

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

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

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

Функциональный блок

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия, первое из которых - понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1), и, по требованиям стандарта, его название должно содержать глагольную форму ("производить услуги", а не "производство услуг").

Каждая из четырех сторон функционального блока имеет своё значение: верхняя сторона - "Управление" (Control), левая сторона - "Вход" (Input), правая - "Выход" (Output), нижняя сторона - "Механизм" (Mechanism). Каждому функциональному блоку в рамках системы присваивается уникальный идентификационный номер.

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

Интерфейсная дуга

Вторым "китом" методологии IDEF0 является понятие интерфейсной дуги (Arrow), которую также нередко называют потоком или стрелкой. Интерфейсная дуга изображается в виде однонаправленной стрелки и имеет свое уникальное наименование (Arrow Label), содержащее, по требованию стандарта, оборот с существительным.

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

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

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

2
Рисунок 2

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

3
Рисунок 3

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

Декомпозиция

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

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

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

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

В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Функциональные блоки диаграммы второго уровня (дочерней - Child diagram) отображают главные подфункции функционального блока контекстной диаграммы и называются дочерними блоками (Child Box). В свою очередь, функциональный блок-предок называется родительским блоком (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram).

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

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

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

Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Символ "туннеля" (Arrow Tunnel) - две круглые скобки вокруг начала интерфейсной дуги - обозначает, что дуга не была унаследована от функционального родительского блока и появилась только на этой диаграмме. "Туннель" вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника означает, что в дочерней по отношению к данному блоку диаграмме эта дуга отображаться и рассматриваться не будет. Как правило, отдельные объекты и соответствующие им интерфейсные дуги "убираются" на промежуточных уровнях иерархии. В этом случае они сначала "погружаются в туннель", а затем "возвращаются из туннеля".

Автор статьи - Геннадий Верников. Его сайт, посвященный консалтингу и реинжинирингу http://vernikov.ru


Главная Загрузить Купить Контакты
©2012 "2П-Кадры!",
All Rights Reserved