Рассмотрим методику построения модели.

Ни одна модель не должна строиться без ясного осознания объекта моделирования и целей моделирования.

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

Примеры вопросов:

- Почему моделируется данный процесс?

- Что должна показывать модель?

- Что выявит данная модель?

- Как ознакомившиеся с этой моделью смогут ее применить?

- Что может получить читатель?

Примеры вопросов для модели деятельности компании:

- Каковы задачи менеджера (служащего)?

- Кто контролирует задачу?

- Какая технология нужна для выполнения каждого шага?

Примеры вопросов для функциональной модели деятельности пользователя ПЭВМ:

- Какие задачи выполняет пользователь?

- Как связано между собой выполнение разных работ пользователя?

- Какие данные необходимы для выполнения каждой из работ?

Вопросы служат основой для четкого и краткого определения цели моделиро­вания (Purpose). Модель не может быть построена без четко сформулированной цели. Цель позволяет команде аналитиков сфокусировать усилия в нужном направлении.

Примеры формулирования цели для функциональной модели деятельности пользователя ПЭВМ:

- "Разработка функциональной модели с целью создания соответствующего ПО";

- "Подготовить функциональную модель деятельности пользователя ПЭВМ при работе с графическими изображениями";

- "Разделить поставленную задачу на более мелкие подзадачи";

- "Определить взаимосвязь работ и задачи каждой из них".

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

- "Реализовать структурную функциональную модель деятельности компании";

- "Подготовить рабочую модель бизнес-процесса управленческого учета для внедрения на предприятии";

- "Определить роли и ответственность служащих для написания должностных инструкций";

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

- "Описать функциональность предприятия с целью написания спецификаций информационной системы" и т.д.

Затем определяется точка зрения (Viewpoint). Модель должна строиться с единой точки зрения, соответствующей цели моделирования.

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

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

Далее необходимо четко определить границы (область) моделирова­ния (Scope) системы в целом и ее основных компонентов. Это основа построения модели.

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

При формулировании области необходимо учитывать два компонента — широту и глубину.

Широта определяет, что будет рассматриваться внутри системы, а что снаружи.

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

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

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

Определение границ — очень важный момент моделирования.

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

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

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

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

Строится контекстная диаграмма IDEF0 — диаграмма "самого верхнего" уровня. Она содержит одну единственную функцию — контекстную функцию.

Затем производится разбиение контекстной функции на крупные фрагменты — декомпозиция (детализация). Строятся диаграммы декомпозиции (рис. 8.15).

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

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

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

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

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

Рис. 8.15. Декомпозиция функции

Примеры диаграмм в нотации IDEF0 для модели "Деятельность пользователя ПЭВМ при работе с графическими изображениями" приведены на рис. 8.16 – 8.19, контекстная диаграмма показана на рис. 8.2.

          Рис. 8.16. Диаграмма декомпозиции контекстной диаграммы функциональной модели в нотации IDEF0                                                                                                                    

Рис. 8.17. Диаграмма декомпозиции процесса А2 "Редактирование изображения" в нотации IDEF0

Рис. 8.18. Диаграмма декомпозиции процесса А2.4 "Редактирование изображений с помощью примитивов" в нотации IDEF0

                                                                                                                                                           

Рис. 8.19. Диаграмма декомпозиции процесса А3 "Настройка изображения" в нотации IDEF0

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

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

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

- подход "в ширину", когда каждая диаграмма максимально детализируется перед своей декомпозицией;

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

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

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

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

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

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

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

Рис. 8.20. Диаграмма дерева узлов в модели "Деятельность пользователя ПЭВМ при работе с графическими изображениями"

Кроме этого, встречаются следующие виды FEO-диаграмм:

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

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

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

8.3. Рекомендации по рисованию диаграмм

В реальных диаграммах к каждому функциональному блоку может подходить и от каждого может отходить около десятка стрелок. Если диаграмма содержит 6 — 8 блоков, то она может содержать 30 — 40 стрелок, причем они могут сливаться, разветвляться и пересекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели.

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

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

- Следует максимально увеличить расстояние между функциональными блоками, поворота­ми и пересечениями стрелок.

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

- Обратная связь по входу рисуется "нижней" петлей, обратная связь по управлению — "верхней" (см. рис. 8.8, 8.9).

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

Рис. 8.21. Пример обратной циклической связи в работе "Определение списка подпапок"

- Следует минимизировать число пересечений, петель и поворотов стре­лок. Это ручная и творческая работа (рис. 8.22).

Рис. 8.22. Минимизация пересечений и поворотов стрелок

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

Рис. 8.23. Пример правильного (справа) и неправильного (слева) расположения

функциональных блоков при изображении связи по входу