Аис1

непомеченные ветви содержат все объекты, принадлежащие сливаемым сегментам указан-ные в общей метке стрелки после слияния, т.е. все объекты исходят из всех ветвей (рис.1);

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

ошибкой является наличие на диаграмме стрелки, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей.

Туннелирование стрелок

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

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

– это будет только перегружать их и делать сложными для восприятия. Возникает необходимость избавиться от отдельных «концептуальных» интерфейсных стрелок и не детализировать их глубже некоторого уровня.

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

Символ «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала стрелки обозначает, что эта стрелка не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца стрелки в непосредственной близи от блока–приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта стрелка отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им стрелки не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

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

Туннелирование рекомендуется применять только опытным аналитикам в случаях,

51

когда диаграммы становятся слишком сложными для чтения и понимания. Помещение стрелок в тоннель осуществляется не просто для удобства - это важный способ точной регулировки модели не столько для описания системы, как для существенного упрощает ее описания.

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

Виды туннельных стрелок

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

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

части модели или непосредственно извне.

Опыт свидетельствует, что ситуации требующие создания туннельных стрелок встречаются редко, и если это все же происходит, то следует применять

52

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

Топология стрелок

Вметодологии IDEF0 существует соглашения по размещению стрелок:

вычерчивание стрелок, независимо от их назначения, выполняется только по вертикали и горизонтали, что позволяет проследить за направлением стрелок и определить блоки как точки сбора стрелок, которыми блоки и являются;

следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки;

следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани блока;

следует максимально увеличить расстояние между поворотами и пересечениями стрелок;

наличие входных стрелок у блока не является его обязательным атрибутом;

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

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

если данные служат и для управления, и для входа, то вычерчиваются только стрелки управления, что уменьшает сложность диаграммы и делает очевидным управляющий характер данных;

расстояние между параллельными стрелками должно быть максимально возможным (с учетом габаритов диаграммы), что позволяет оставить больше места для меток и помогает зрительно определять количество стрелок и прослеживать их пути;

расстояние между блоками и поворотами стрелок должно быть максимально

53

возможным (с учетом габаритов диаграммы), что позволяет облегчить процесс чтения и уменьшить веро-ятность перепутать две разные стрелки;

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

обратные связи по управлению вычерчиваются «вверх и над» («верхняя» петля), что позволяет указать ограничивающие обратные связи при минимальном числе линий и пересечений, а также собрать все стрелки управления в правой верхней части диаграммы;

обратные связи по входу вычерчиваются «вниз и под» («нижняя» петля), что позволяет ука-зать обратные потоки данных при минимальном числе линий

ипересечений, а также собрать все входные стрелки в левой нижней части диаграммы;

обратные связи посредством механизма должны быть показаны как «вниз и под»;

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

иногда разрешается выделять буферы и повторно используемые объекты;

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

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

если возможно, стрелки присоединяются к блокам в одной и той же ICOMпозиции. Тогда соединение стрелок конкретного типа с блоками будет согласованным, и чтение диаграммы упростится;

при соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки;

блоки (функции) являются сопряженными через среду, если они имеют связи

с источником, генерирующим данные, без конкретного определения отношения отдельной части данных к какому-либо блоку;

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

необходимо использовать (где это целесообразно) выразительные возможности ветвящихся стрелок;

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

54

Диаграммы

Основу методологии IDEFO составляет графический язык описания процессов в виде иерархии функциональных схем, называемых функциональными диаграммами. Модель системы в нотации IDEFO – это совокупность иерархически упорядоченных и логически связанных диаграмм модели, созданных на основе ранее определенного субъекта, цели и точки зрения, каждая из которых имеет название, располагающееся в центре нижней части ее бланка/каркаса, при этом, чем выше уровень диаграммы, тем она менее детализирована.

ДИАГРАММА – это основная единица описания системы, расположенная на отдельном листе и имеющая собственные синтаксические правила, отличающиеся от синтаксических правил описания модели. Диаграмма представляет собой тщательно согласованный набор взаимосогласованных описаний, начиная с описания системы самого верхнего уровня и кончая подробным описанием деталей или операций системы, позволяющих определить различные системные функции и показать взаимосвязь и взаимное влияние этих функций. К назначению создаваемых диаграмм можно отнести то, графическое изображение модели является предметом экспертизы, т. е. обсуждение диаграммы со специалистами конкретной предметной области.

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

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

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

возможных интерпретаций.

Контекстная диаграмма

Контекстная диаграмма - вид IDEF0-диаграммы. Это диаграмма, расположенная на вершине древовидной структуры диаграмм, представляющая собой самое общее

55

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

Контекстная диаграмма A-0 должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиции которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект.

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

Стрелки на контекстной диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представля-ют полный комплект внешних интерфейсов объекта. Контекстная диаграмма имеет узловой номер A-n (n?0), которая представляет контекст модели. Диаграмма верхнего уровня обозначается идентификатором «А-0» (произно-сится «А минус ноль»), на которой объект моделирования представлен единственным блоком с граничными стрелками, устанавливает область моделирования, определяет границы модели и является обязательной контекстной диаграммой. Диаграммы с узловыми номерами А-1, A-2,... - дополнительные контекстные диаграммы.

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

Разработка контекстной диаграммы

Разработка контекстной диаграммы включает определение:

субъекта моделирования - определение, что входит в состав модели, а что из нее исключено;

56

цели, как критерия окончания моделирования;

точки зрения модели, как определение объема, состава информации и формы подачи ин-формации;

ограничений, налагаемые на объект;

построение диаграммы верхнего уровня и ее обобщение.

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

При формировании области моделирования необходимо учитывать два параметра:

ширина - это границы модели. Ширина модели определяет, что будет рассматриваться внутри системы, а что снаружи;

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

существующие взаимосвязи.

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

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

В ходе процесса декомпозиции контекстной диаграммы аналитик выполняет следующие шаги:

изучает моделируемый объект с целью представления его в виде функций;

составляет список данных с целью возможности представления в виде стрелок;

составляет список функций;

преобразует функции в блоки;

формирует взаимосвязи между блоками на основании созданного списка стрелок;

создает диаграмму декомпозиции.

Пример контекстной диаграммы для САПР редуктора приведен на рисунке 1. В результате стандартной интерпретации графических обозначений IDEF0

устраняется неоднозначность описания системы на естественном языке. Например, фразе «Функция В пре-образует I в О при ограничениях, заданных С, с помощью М»

57

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

Диаграммы декомпозиции

ДИАГРАММЫ ДЕКОМПОЗИЦИИ предназначены для детализации функций и получаются при разбиении контекстной диаграммы на крупные подсистемы (функциональная декомпозиция) и описывающие каждый подсистему и их взаимодействие.

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

Хотя действительной вершиной модели является диаграмма уровня А-0, настоящей «рабочей вершиной» является диаграмма А0, поскольку она является уточненным выражением точки зрения модели. Ее содержание показывает, что будет рассматриваться в дальнейшем, ограничивая последующие уровни в рамках цели проекта. Нижние уровни уточняют содержание функциональных блоков, детализируя их, но, не расширяя границ модели.

По методологии IDEF любая декомпозиция начинается с создания и изучения диаграммы АО с целью определения блока, декомпозиция которого выявит основные аспекты диаграммы АО и будет оказывать большое влияние на декомпозиции других блоков этой диаграммы. При выборе такого самого содержательного блока желательно учитывается доминирование, функциональную сложность и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы. После построения диаграммы А0, ее данные обобщаются на диаграмме А-0. Для получения хорошей основы для декомпозиции имеет смысл несколько раз переключиться с проработки диаграммы А-0 на диаграмму А0 и обратно.

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

58

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

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

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

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

Имея неструктурированные перечни объектов и функций, приступают к прорисовке отдельных блоков и соединению их при помощи стрелок. Скорее всего, первоначально созданную диаграмму придется несколько раз модифицировать, разбивая ее блоки на части или объединяя их, чтобы добиться максимальной наглядности. Для более точного отображения деталей и выяснения “узких мест”, требующих уточнения, лучше создавать сразу от 2 до 4 диаграмм, отслеживая, таким образом, их взаимосвязи.

Диаграмме может быть поставлен в соответствие структурированный текст, представляющий собой краткий комментарий к содержанию диаграммы. Текст, относящийся к представленной диаграмме, поясняет, каким образом она соответствует поставленным целям и точке зрения, делая материалы более понятными для читателей. При этом текст лаконично описывает процесс, представленный именно на текущей диаграмме, не дублируя то, что очевидно из ее содержания. Текст используется для объяснений и уточнений характеристик, потоков и т.д. Текст не должен использоваться для описания и без того понятных блоков и стрелок на диаграммах. По окончанию создания диаграммы к ней, как правило, прилагаются сопроводительный текст, глоссарий и иногда FEO диаграмма. Для обеспечения наглядности диаграмм, а, следовательно, и графических изображений модели рекомендуется, чтобы каждая функция/блок на любой диаграмме должна быть декомпозирована в виде диаграммы из 3-6 блоков на следующем уровне с целью более подробного раскрытия его содержания. Эти ограничения позволяют осуществить детализацию постепенно с обеспечением

59

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

Дочерняя диаграмма

ДОЧЕРНЯЯ ДИАГРАММА, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Каждая обычная (не контекстная) диаграмма является дочерней диаграммой, поскольку, по определению, она подробно описывает некоторый родительский блок. Дочерняя диаграмма как бы вложена в свой родительский блок.

Любая (не контекстная) диаграмма может быть как родительской диаграммой (содержать родительские блоки), так и дочерней (подробно описывать собственный родительский блок). Аналогично, блок может быть как родительским (подробно описываться дочерней диаграммой) так и дочерним (появляющимся на дочерней диаграмме).

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

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

60