---

ICOM-кодами. ICOM (аббревиатура от Input, Control, Output и Mechanism) – коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер. Граничные стрелки необходимо соединить с соответствующими входами, выходами и т. п. активностей диаграммы декомпозиции.

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

Связь по входу (output-input),когда стрелка выхода вышестоящейработы (далее – просто выход) направляется на вход нижестоящей работы (рисунок 3.2). На рисунках 3.5 – 3.6 в основном показаны только рассматриваемые связи.



Рисунок 3.2 - Связь по входу
Связь по управлению (output-control),когда выход вышестоящейработы направляется на управление нижестоящей (рис. 3.3). Связь по управлению показывает доминирование вышестоящей работы.



Рисунок 3.3 - Связь по управлению
Обратная связь по входу (output-input feedback),когда выходнижестоящей работы направляется на вход вышестоящей (рисунок 3.4). Такая связь, как правило, используется для описания циклов.



Рисунок 3.4 - Обратная связь по входу
Обратная связь по управлению (output-control feedback),когдавыход нижестоящей работы направляется на управление вышестоящей (рисунок 3.5). Обратная связь по управлению часто свидетельствует об эффективном управлении бизнес – процессами.

Связь выход-механизм (output-mechanism),когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рисунок 3.6).



Рисунок 3.5 - Обратная связь по управлению


Рисунок 3.6 - Связь выход-механизм

---

Простейшим и наиболее распространенным видом стрелок является явная стрелка,которая имеет источником одну-единственную активность иназначением тоже одну -единственную активность . Одни и те же данные или объекты, порожденные одной активностью, могут использоваться сразу в нескольких других активностях. С другой стороны, стрелки, порожденные в разных активностях, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления. Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления. Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. Правила именования сливающихся стрелок полностью аналогичны – ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после чего вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня , или наоборот – отдельные дуги нижнего уровня отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования.

Вновь созданные на диаграмме декомпозиции граничные стрелки изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рисунок 3.7).

---

Рисунок 3.7 - Неразрешенная (unresolved) стрелка
Можно разрешить миграцию новой стрелки на диаграмму верхнего уровня или не разрешить такую миграцию. В последнем случае говорят, что стрелка будет туннелирована. В BPwin для этого нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel. Появляется диалог Border Arrow Editor. Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel – стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце.

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

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

1. 
   Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия . Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:
   

---

• 
  Что поступает в подразделение "на входе"?
  
• 
  Какие функции и в какой последовательности выполняются в рамках подразделения?
  
• 
  Кто является ответственным за выполнение каждой из функций?
  
• 
  Чем руководствуется исполнитель при выполнении каждой из функций?
  
• 
  Что является результатом работы подразделения (на выходе)?
  

2. 
   На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
   
3. 
   Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 – читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
   
4. 
   Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление предприятии (системе) с заданной точки зрения и для заданной цели.
   

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

3.3 Методология DFD
Целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (DataFlowDiagram – DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации,хотя допускают и представлениедругих объектов.

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

• 
  потоки данных;
  
• 
  процессы (работы) преобразования входных потоков данных в выходные;
  
• 
  внешние сущности;
  
• 
  накопители данных (хранилища).
  

---

Смотрите также файлы

• Практикум по курсу Базы данных для студентов.docx

• Р. А.адырлов, Н.. Беристемова.docx

• Контрольная работа по дисциплине Электромагнитная совместимость и средства защиты Тема Расчет характеристик питания нагрузок в сети электроснабжения железных дорог.docx

• Цифровые компетенции Цифровая безопасность Цифровое потребление.docx

• Специальные пожарные автомобили.doc