Letyshops

Основные методологии обследования организаций. Стандарт IDEF0

Геннадий Верников
get@psi.ru, http://consulting.psi.ru
Окончание.
Декомпозиция | Глоссарий | Ограничения сложности IDEF0-диаграмм / Групповая работа над разработкой модели | Российские особенности IDEF0-моделирования

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

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

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

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

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

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

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

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

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

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

[1][2][3][4] следующая>>
[вид для печати]
© Геннадий Верников

 

 

Реклама: