<<
>>

МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0

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

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

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

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

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

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

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

Создаваемая IDEF0-модель имеет конкретное назначение, называемое целью модели.

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

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

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

Компоненты синтаксиса IDEF0-диаграмм - функциональные блоки и дуги (стрелки). Функциональные блоки представляют функции, определённые как действия, процессы или преобразования. Дуги представляют данные или объекты, связанные с функциями.

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

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

Изображение дуг должно соответствовать следующим синтаксическим правилам:

- чертятся только горизонтально или вертикально;

- при изгибе могут быть изогнуты под прямым углом;

- должны касаться внешней границы блока, но не должны входить в блок;

- должны присоединяться к сторонам блока, но не к углам.

Между данными (объектами) и функциями возможно четыре вида отношений: вход, управление, выход и механизм. Каждый вид изображается дугой, связанной с определённой стороной блока (рис. 8): левая сторона предназначена для входных дуг (входов), правая - для выходных (выходов), верхняя сторона - для управленческих дуг и нижняя - для дуг механизмов.

Рис. 8. Отношения между блоками и дугами

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

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

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

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

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

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

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

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

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

Дуга на диаграмме редко изображает один объект или одни данные. Обычно она отражает их набор, поэтому дуги могут разветвляться и соединяться различными сложными способами. Разветвление дуг, изображаемое в виде расходящихся линий, означает, что всё содержимое дуг (или его часть) может появиться в каждом ответвлении дуги. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами (рис. 10):

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

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

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

Кроме того, каждая ветвь перед слиянием может помечаться в соответствии со следующими правилами (рис. 10):

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

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

Рис. 9. Пример доминирования блоков на диаграмме

Рис. 10. Примеры разветвления и слияния дуг

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

- вход-управление;

- выход-вход;

- обратная связь по управлению;

- обратная связь по входу;

- выход-механизм.

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

Отношение выход-вход возникает тогда, когда выход одного блока становится входом для блока с меньшим доминированием.

Более сложны обратные связи, поскольку они отражают итерационные процессы - результаты работы функции (выходы) влияют на выполнение других функций, которые впоследствии влияют на исходную функцию. Различают описание двух видов обратной связи: обратная связь по потоку данных (по входу) и по управлению.

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

Рис. 11. Обратная связь по потоку данных

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

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

Для полного описания системы требуется набор IDEFO-диаграмм, образующих IDEFO-модель.

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

На контекстной диаграмме должны быть указаны точка зрения модели и цель её создания.

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

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

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

Рис. 12. Обратная связь по управлению

Узловые номера используются для того, чтобы указать положение диаграммы в иерархии модели. Все узловые номера графических диаграмм начинаются с буквы «А» («АсДои» - действие). Исходная для данной модели контекстная диаграмма имеет узловой номер А0. Диаграмма с узловым номером А21 детализирует блок 1 на диаграмме А2. Подобным же образом А2 детализирует блок 2 на диаграмме А0, которая является самой полной диаграммой модели.

Стандарт моделирования требует, чтобы все внешние дуги диаграммы были согласованы по числу и наименованию (но не обязательно по расположению) с дугами, касающимися декомпозированного блока родительской диаграммы. Для этих целей принята система обозначений. Схема кодирования дуг ICOM (от слов: Input (вход), Control (управление), Output (выход), Mechanism (механизм)) позволяет точно идентифицировать и проверить связи по дугам между диаграммами. Код дуги состоит из буквы и цифры. После каждой буквы добавляется цифра, соответствующая положению данной дуги среди других дуг того же типа, касающихся родительского блока. Причём входные и выходные дуги пересчитываются сверху вниз, а дуги управления и механизмов - слева направо (рис. 13).

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

Рис. 13. Кодирование дуг

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

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

Диаграммы следует оформлять с учётом следующих правил.

1. Модель должна включать контекстную диаграмму A0, содержащую только один блок (его номер 0).

2. Неконтекстная диаграмма должна иметь не менее трёх (но не более шести) блоков.

3. Каждый блок на неконтекстной диаграмме следует пронумеровать внутри в нижнем правом углу (от 1 до 6).

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

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

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

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

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

9. Обратные связи по управлению рекомендуется рисовать «вверх и над» (рис. 11), а обратные связи по входу следует рисовать «вниз и под» (рис. 12).

10. Открытые граничные дуги, которые представляют одни и те же данные (объекты), должны быть связаны через ветвление. Множественные источники, которые представляют одни и те же данные (объекты), должны объединиться, чтобы формировать единую дугу вывода.

1.3.

<< | >>
Источник: В.В. Быковский Н.В. Мартынова Л.В. Минько, В.Л. Пархоменко О.В. Коробова, Е.М. Королькова, Е.В. Быковская, Г.М. Золотарёва. Технологии финансового менеджмента : учебное пособие. В 3 ч. / В.В. Быковский, Н.В. Мартынова, Л.В. Минько, В.Л. Пархоменко, О.В. Коробова, Е.М. Королькова, Е.В. Быковская, Г.М. Золотарёва. - Тамбов : Изд-во ГОУ ВПО ТГТУ,2010. - Ч. 3. - 80 с.. 2010

Еще по теме МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0:

  1. История возникновения методологии IDEE
  2. Порядок проведения работ по определению, классифиюции и идентификации процессов.
  3. Вопросы для самопроверки знаний
  4. Второй уровень бизнес-моделирования
  5. МОДЕЛИ И МОДЕЛИРОВАНИЕ ПРИ ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
  6. МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0
  7. ОГЛАВЛЕНИЕ
  8. Методика проведения обследования бизнес-процессов компании связи
  9. 2.1 Организационное проектирование на основании использования типовых структурных схем