Город филадельфия

Перевод стандарта IDEF0

Федеральный стандарт по обработке информации Публикация 183 21 Декабря 1993 Объявление стандарта

Методология функционального моделирования (IDEF0)

Федеральные стандарты обработки информации (FIPS PUBS) публикуются Национальным институтом стандартов и технологий после утверждения министром торговли в соответствии с разделом 111 (d) Закона о федеральной собственности и административных услугах 1949 года с поправками, внесенными Законом о компьютерной безопасности 1987 года, Публичный закон 100-235.

Название стандарта

Методология функционального моделирования (IDEF0).

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

Стандарт программного обеспечения, методы моделирования.

Пояснение

Данная публикация объявляет о принятии Методологии функционального моделирования (IDEF0) в качестве Федерального стандарта обработки информации (FIPS). Настоящий стандарт основан на программе интегрированной компьютеризации производства научно-исследовательских лабораторий ВВС Райт (ICAM), Часть II, том IV Руководство по функциональному моделированию (IDEF0), Июнь 1981 года. Настоящий стандарт описывает язык моделирования IDEF0 (семантика и синтаксис), а также связанные с ним правила и методы разработки структурированных графических представлений системы или предприятия. Использование стандарта позволяет создавать модели, описывающие системные функции (действия, поведение, процессы, операции), функциональные связи и данные (информация или объекты), которые поддерживают интеграцию систем. Этот стандарт является информационно-справочным документом, предназначенным для системных или корпоративных разработчиков моделей, применяющих IDEF0 для определения инструментов при реализации этой методики и других компьютерных специалистов для понимания точных синтаксических и семантических правил стандарта.

Утверждающий орган

Министр торговли.

Агентство по техническому обслуживанию

Другие документы

a. Архитектура ICAM, Часть II-том IV Руководство по функциональному моделированию (IDEF0), AFWAL-TR-81-4023, Лаборатория материалов, Авиационные лаборатории ВВС Райт, Командование ВВС, База ВВС Райт-Паттерсон, Огайо 45433, июнь 1981 г.

Сопутствующая документация

a. Федеральные правила управления информационными ресурсами, подраздел 201.20.303 Стандарты и подраздел 201.39.1002 Федеральные стандарты.
b. Интегрированная система информационной поддержки (IISS), том V Подсистема общей модели данных, Часть 4 Руководство по информационному моделированию Idef1 Дополненное, декабрь 1985 г.
c. Архитектура ICAM, часть II, том V Руководство по информационному моделированию (IDEF1), AFWAL-TR-81-4023, Лаборатория материалов, Авиационные лаборатории ВВС Райт, Командование ВВС, База ВВС Райт-Паттерсон, Огайо 45433, июнь 1981 г.
d. Управление конфигурацией ICAM, том II Стандарты документации ICAM при разработке систем (SDM), AFWAL-TR-82-4157, Командование ВВС, Авиабаза Райт-Паттерсон, Огайо 45433, октябрь 1983 г.

Цели

Основными целями настоящего стандарта являются:

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

b. Предоставить методику моделирования, не зависящую от методов или инструментов компьютерной программной инженерии (CASE), но которая может быть использована в сочетании с этими методами или инструментами;

c. Предоставить методику моделирования, обладающую следующими характеристиками:

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

Применение

Использование данного стандарта настоятельно рекомендуется если в ходе реализации проектов требуется:

a. применение методики моделирования для анализа, разработки, реинжиниринга, интеграции или приобретения информационных систем;

b. включение метода системного или корпоративного моделирования в методологию анализа бизнес-процессов или разработки программного обеспечения.

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

a. в проектах, требующих IDEF0 в качестве метода моделирования;

b. при разработке автоматизированных программных средств, реализующих методику моделирования IDEF0.

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

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

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

Технические характеристики

Настоящий стандарт принимает Методологию функционального моделирования (IDEF0) в качестве Федерального стандарта обработки информации (FIPS).

Реализация

Реализация стандарта включает в себя два момента: приобретение разработки и интерпретация стандарта.

Приобретение пакета IDEF0

Вступление в силу и требования

Публикация FIPS 183 вступает в силу 30 июня 1994 года. Приобретение продукта после этой даты федеральными структурами, которые работают с методологией функционального моделирования IDEF0 или используют программное обеспечение, реализующее этот метод, должно соответствовать требованиям FIPS 183. Соответствие данному стандарту обязательно, независимо от того, приобретается ли продукт в рамках закупки системы ADP или отдельными закупками, используется ли в рамках лизингового соглашения ADP или указано для использования в контрактах на услуги программирования.

Переходный период

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

Интерпретация Федерального стандарта обработки информации (FIPS)

Национальный институт по стандартизации и технологии предоставляет разъяснения относительно реализации и применимости Федерального стандарта обработки информации. Все вопросы, касающиеся толкования стандарта, следует адресовать директору Лаборатории компьютерных систем в Гейтерсберге, Мэриленд, по указанному адресу.

Обращение о отказе от выполнения требований стандарта

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

Адрес для обращений: Гейтерсберг, Мэриленд 20899

Markdown

Кроме того, уведомление о каждом утвержденном отказе и делегировании полномочий по утверждению отказов незамедлительно направляется в Комитет по правительственной деятельности Палаты представителей, в Комитет по правительственным делам Сената и публикуется в Федеральном реестре.

Если определение об отказе применяется к закупке оборудования и / или осуществлению услуг, уведомление о решении выдать отказе должно быть опубликовано в Commerce Business Daily как часть уведомления о предложении и приобретении или, если отказ принимается после публикации этого уведомления путем внесения изменений в такое уведомление.

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

13. Где можно приобрести данный стандарт: Экземпляры этой публикации продаются Национальной службой технической информации Министерства торговли США, Спрингфилд, Вирджиния 22161. При оформлении заказа укажите Публикацию 183 Федеральный стандарт обработки информации (FIPSPUB 183) и название. Оплата может быть произведена чеком, денежным переводом или депозитным счетом.

Важные особенности моего перевода

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

Стрелки

Стрелки в нотации IDEF0 могут быть нескольких типов:

• Input
• Output
• Control

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

Из всех четырех названий, на самом деле, правильное только одно – Механизм. Про Вызов многие и не пишут. На самом деле, Input – это не «входящие», правильный перевод слова «ввод», т.е. это стрелка ввода или, если использовать прилагательные, вводящая стрелка. Почему это важно? Если мы с концептуальной точки зрения говорим о входящем, это значит, что у нас что-то входит. Т.е. где-то есть вход, кто-то или что-то туда входит, есть момент, когда этот кто-то или что-то находится перед входом, а потом – после входа и далее все, что с этим связано. А если мы говорим слово «ввод», подразумевается, что мы должны что-то ввести. В результате мы концентрируемся не на том, что мы входим куда-то, не на поиске входа, а на том, что именно нужно ввести. Самый простой пример использования слова Input – это клавиатура и мышка, устройства ввода информации. Никто не называет их устройствами входящей информации или еще как-то. И мы понимаем, почему это устройства ввода, ведь с их помощью мы вводим информацию, а не входим куда-то. И сами мышка и клавиатура также никуда не входят, а только служат устройствами для ввода. Аналогично и стрелки в IDEF0, они никуда не входят. С их помощью мы вводим в функцию данные и/или объекты. Схожая ошибка заключается в переводе Output. Стрелка никуда не исходит, она, как устройство вывода, выводит определенный результат (материальный или информацию). И здесь также мы должны концентрироваться на вопросе, что мы выводим, а не интересоваться, где выход, или изучать моменты до и после выхода. Т.е. вывод – это слово правильное и точное.

Следующая ошибка – перевод названия стрелки Control, которую почему-то все называют управляющей или стрелкой управления. Я предполагаю, что это просто ошибка, которую, кстати, я тоже в своем первом обзоре IDEF0, допустил. Но даже тогда, когда я использовал название из прочитанных ранее публикаций, у меня в голове не складывалось, почему это управление? Управление – это слишком общее и неточное понятие. Кстати, именно этот вопрос стал для меня первым шагом к изучению англоязычной документации. И тогда все стало на свои места. Слово Control переводится как контроль. И стрелки Control – это то, что контролирует, что ограничивает функцию. Говорить стрелки управления – неправильно. Ведь они на самом деле ничем не управляют. Управляет чем-то обычно человек, иногда – механизм, в животном мире – вожак стаи. Но всегда это кто-то или что-то. А если мы говорим о контроле, речь идет об ограничениях. Т.е. стрелки Control показывают, какие ограничения у нас есть (это становится понятно из текста самого стандарта).

Например, для функции «создать программу» у нас может выступать в качестве ограничения требования к скорости работы. При этом скорость работы назвать управлением несколько нелепо. Этот параметр ничем не управляет, но ограничивает наш выбор.

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

Количество блоков

Практически во всех русскоязычных обзорах IDEF0 пишут (и я сам делал эту ошибку), что блоков должно быть 7 штук. В стандарте четко указано, что диаграмма может содержать от 3 до 6 блоков. Таким образом, компиляции нас не просто дезинформируют, но вынуждают нарушать требования стандарта. Есть множество таких нюансов, но я не стану заострять на них внимание. Приятного чтения!

ПРИЛОЖЕНИЕ С-ПРОЦЕДУРЫ И ФОРМЫ ЦИКЛА ОБЗОРА

Создание модели – это динамичный процесс, который обычно требует командной работы. На протяжении всего проекта черновые фрагменты модели создаются авторами и распределяются между другими участниками проекта, экспертами по объекту, менеджментом и т. д. для обзора и комментариев. Черновые фрагменты модели называются Комплектами и могут содержать диаграммы, текст, глоссарий или любую другую информацию, которая, по мнению автора, имеет отношение к разработке модели. Для правильного чтения и понимания моделей IDEF0 требуется непродолжительное обучение и скромный опыт. Глубокое понимание темы необходимо для обеспечения гарантии качества IDEF-моделирования, предоставляемое командой. Каждый, кто достаточно глубоко продвинулся в правильном чтении, называется «читателем».

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

C.2 Цикл Комплекта IDEF

Рисунок С1. Цикл Комплекта

Этапы цикла Комплекта следующие:

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

C.2.1 Роли персонала

Роли и функции вовлеченных людей заключаются в следующем:

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

C.2.2 Руководство для разработчиков (авторов), читателей и комментаторов

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

C.2.2.1 Руководство для читателей

Единый набор вопросов и правил не может быть предложен для комментирования, так как тематика, стиль и техника сильно отличаются друг от друга. Однако существуют руководящие принципы, обеспечивающие повышения качества. Основными критериями качества являются: будет ли документ составлен и оформлен так, чтобы быть понятным целевой аудитории? Достигает ли он своей цели? Является ли он правильным и точным, учитывая ограниченный контекст? Общие руководящие принципы при комментировании таковы:

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

C.2.2.2 Взаимодействие разработчика с комментатором

Назревшее совещание организуется следующим образом:

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

C.3 Комплекты IDEF

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

Существует два вида Комплектов IDEF:

Стандартный комплект предназначен для комментариев. Он считается «рабочим документом», призванным помочь разработчику в уточнении его общей модели.

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

Стандартные Комплекты содержат части модели и часто представляются по мере выполнения работы. Стандартные комплекты представляются на рассмотрение в рамках Цикла комплектов IDEF и относятся к типу, упомянутому в остальной части настоящего приложения. Комплекты обновления представляются через регулярные промежутки времени. Эти Комплект включают в себя последнюю версию модели. От получателей комплектов обновления не предполагается получение комментариев, хотя они могут сделать это по своему усмотрению. Комплекты обновления хранятся получателями в архиве.

C.3.1 Заполнение Титульного листа Комплекта

В соответствующем Титульном листе представлен материал в виде Комплекта. Титульный лист содержит поля для разработчика, даты, проекта, номера документа, названия, статуса и примечаний. Подготовьте Титульный лист для каждого представленного Комплекта и заполните поля пояснительной записки, как представлено на Рисунке С2.

Рисунок С3. ФОРМА СОДЕРЖАНИЯ КОМПЛЕКТА IDEF

C.3.2 Подготовка стандартного Комплекта

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

Соберите полезные материалы и приложите их для удобства читателя. Никогда не используйте дополнительный материал для передачи информации, которая должна содержаться в самой диаграмме. По возможности, используйте наиболее естественные средства коммуникации диаграммы, выделяйте детали, которые важны для понимания концепции читателями. Объедините материал с заполненным Титульным листом и листом Содержания Комплекта (Рисунок С3) и отправьте все в библиотеку.

C. 4 Стандартная форма диаграммы

Форма диаграммы IDEF (Рисунок С4) имеет минимальную структуру и ограничения. Форма включает в себя только те функции, которые важны для структурированного анализа, а именно:

Форма диаграммы имеет стандартный размер для удобства передачи и копирования. Форма разделена на три основных раздела:

Форма диаграммы должна использоваться для информации. представляемой в письменном виде.

Рисунок С4. Стандартная форма диаграммы

Форма составлена таким образом, что Рабочие информационные поля, расположенные в верхней части формы, могут быть убраны после заполнения окончательной версии «одобренной к публикации». Идентификационные поля располагаются вертикально друг под другом, когда формы (с необрезанной верхней частью) прикрепляются кнопками, в порядке сверху вниз к доске или стене. Открытые полосы идентификационного поля выступают в качестве буквенные указатели, расположенные в порядке индекса ноды. Если соблюдается формат двусторонней публикации «пара страниц», когда нижняя часть страницы с текстом и контекстом обращены к переплету, то поле сообщения на странице становится видимым, при поднимании вверх каждой предшествующей страницы, закрепленной на стене.

C.4.1 Рабочая информация

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

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

C.4.1.3 Поле «Статус»

Классификации статусов указывают на стадии утверждения, а именно:

C.4.1.4 Поле «Читатель/Дата»

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

C.4.1.5 Поле " Контекст”

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

Рисунок С5. Иллюстрация контекстного поля

Возникают следующие особые случаи: 1) Контекстное поле требуемой формы контекстной диаграммы A-0 «TOP», записанное в центре поля. 2) Контекстное поле дополнительной контекстной диаграммы высокого уровня A-1 это A-2, эскиз, если имеется такая контекстная диаграмма более высокого уровня, и аналогично для A-n, где n = 2 или более. 3) Контекстное поле для контекстной диаграммы высшего уровня, A-n, для самого большого n (= 1 или больше) «NONE». Иллюстративный пример см. на рис.21.

C.4.1.6 Поле «Используется в» (“Used At”)

Это список диаграмм, помимо родительского контекста, которые каким-либо образом используют или ссылаются на данную страницу формы диаграммы.

Чаще всего используется перечисление одной или нескольких ссылок нод на подмодели, для которых родительский блок этой дочерней диаграммы обеспечивает поддержку вызовов при детализации этого дочернего элемента. При необходимости (случай n=1 принимается условно), выражение “node_reference_expression” (которое начинается с «model_name/», за которым следует номер узла) заканчивается «Mn», n больше или равно 2, превращая ссылку в полную ICOM-кодовую ссылку на конкретную стрелку механизма высшего блока поддерживаемой подмодели. Например,” TLS/A34M2“, записанное в поле Used At для дочерней диаграммы” MN/A211“, утверждает, что родительский блок” MN/A21 “обеспечивает поддержку механизма через вторую стрелку механизма его верхнего блока для подмодели " TLS/A34.”

При такой поддержке удаленной субмодели, указанной в поле «Used At», любой дочерний блок на дочерней диаграмме (а более обще, родительский блок, предоставляющий поддержку, или любые дочерние блоки) могут быть призваны поставлять деталей для некоторого доступного дочерненго блока (рассматриваемого как верхний блок субмодели), чья ссылка на ноду появляется в поле «Used At.» Доступный дочерний блок это блок, доступный по стрелке поддержки механизма ветвления, источником которого является ICOM-код, подключенный к поддержке механизма. Если верхняя часть диаграммы отрезана для публикации, то содержимое поля Used At должно быть скопировано в поле Message в виде n -note (примечание к модели).

C.4.2 Поле " Сообщение” (“Message”)

Поле «Сообщение» содержит основное сообщение, которое должно быть передано. Это поле обычно используется для построения диаграмм с помощью графического языка IDEF. Однако оно может быть использовано для других целей: глоссарий, контрольные списки, заметки, эскизы и т. д. Участники проекта не должны использовать никаких других документов, кроме форм диаграмм, чтобы система регистрации на основе ссылочных номеров могла обеспечить полную запись проекта. Этому может способствовать поддержка инструмента IDEF, включающего в себя электронную почту и доску объявлений, с автоматическим присвоением каждому участнику С-нумерации и «предпочтений».

C.4.3 Поле «Нода» (“Node” )

Это поле содержит полную ссылку на ноду для листа (включая model_name, косую черту, номер ноды и “F “(для FEO),” T “(для текста) или” G “(для глоссария) —с номером страницы” 1 “или” 2 " и т. д. и прилагается в конце, чтобы указать переполнение страниц, если это необходимо), так что лист однозначно определен для справочных и других целей.

C.4.4 Поле «Название» (“Title”)

Поле «Название» содержит название материала, представленного на Форме диаграммы. Если поле «Message» содержит диаграмму, то содержимое поля «Title» должно точно соответствовать имени, написанному в родительском блоке.

С.4.5 Поле «Номер» (“Number”)

Большая область содержит С-номер. С-номер состоит из двух или трех букв инициалов разработчика (выбранных для того, чтобы быть уникальными среди участников проекта), за которыми следует номер, присвоенный разработчиком. C-номер помещается в левом нижнем углу поля “Number” и является основным средством ссылки на сам лист, поскольку используемый лист как форма диаграммы может быть создан только один раз. Каждая форма диаграммы, используемая разработчиком, получает уникальный C-номер, который обычно должен быть первой меткой, указанной на форме.

Если в проекте принято решение отслеживать историю версий, то C-номер формы диаграммы, для которой этот лист является измененной версией, должен быть записан в скобках (пробел необязательный) после записи C-номера разработчика в поле «C-номер». Например, “AB34 (CD123) “означает, что этот лист (”AB34“) предназначен для замены уже существующего”CD123".

При публикации модели номер С может быть заменен стандартным порядковым номером страницы (например, «стр. 17»).

C.4.5.2 Поле " Номер” (“Number”) («Номер страницы Комплекта» Малая прямоугольная Область)

Номер страницы Комплекта записывается библиотекарем в правой части поля “Number” внутри небольшого прямоугольника. Он состоит из номера документа, за которым следует буква, идентифицирующая лист внутри документа.

C.5 Хранение файлов

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

C.6 Процедура обзора модели IDEF

В дополнение к Циклу комплектов была разработана пошаговая процедура в качестве руководства для представления информации о модели группе «рецензентов» (возможно, не имеющих опыта самостоятельного анализа моделей IDEF0 ). Она не заменяет процесс обзора цикла «Читатель/Разработчик», который является центральным для обеспечения качества моделирования IDEF0 (поясняется в C.2), но может быть полезна при периодическом использовании проекта на техническом уровне, чтобы предоставить возможность всем участникам обмениваться или разрабатывать общие интерпретации, которые могут не проявляться в индивидуальных обменах на основе Комплекта.

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

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

Шаг 1: Сканирование диаграммы.

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

Если проблема недостаточно очевидна, критический разбор может быть отложен до следующего шага 3. Однако первое впечатление должно быть сформировано. Проблемы могут быть указаны на магнитно-маркерной доске пока не будут решены

Шаг 2: Анализ родителя.

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

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

Шаг 3: Объедините родительский блок и детализированную диаграмму.

На этом шаге проверяются подсоединения стрелок интерфейса от родителя к дочерним элементам.

Выполните обход по часовой стрелке всех четырех сторон родительского блока, проверяя каждую стрелку, что обеспечит выявления соответствия граничных стрелок кодов ICOM родительским стрелкам.

Шаг 4: Проанализируйте шаблон внутренней стрелки.

Шаблон из блока и стрелок является основным представлением создаваемой модели.

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

Шаг 5: Ознакомьтесь со вспомогательной документацией.

На этом этапе рассматриваются вопросы, которые разработчик выделил в тексте, глоссарии и диаграмме-иллюстрации FEO.

Шаг 6: Установите статус диаграммы.