Принципи побудови моделі IDEF0 у BPwin

Процес моделювання будь-якої системи в IDEF0 у BPwin починається з визначення контексту, тобто найбільш абстрактного рівня опису системи в цілому. У контекст входить визначення суб'єкта моделювання, мети і точки зору на модель. Під суб'єктом розуміється сама система. Основним завданням є визначення складових системи і зовнішніх дій. На визначення суб'єкта системи суттєво впливає точка зору (позиція), з якої розглядається система, і ціль моделювання, тобто спочатку необхідно визначити область моделювання. Опис області як системи в цілому, так і її компонентів, є основою побудови моделі. В процесі моделювання область може коректуватися, але сформульована вона повинна бути спочатку, оскільки область визначає напрям моделювання і критерії завершення процесу моделювання. При формулюванні області необхідно враховувати широту і глибину моделі (системи). Широта має на увазі визначення меж моделі – кількість компонент всередині і поза системою і їх зв'язком. Глибина визначає рівень деталізації моделі.

Визначення меж моделі припускає, що нові об'єкти не будуть внесені в модельовану систему, оскільки внесення нового об'єкту може змінити існуючі взаємозв'язки в системі (проблема "плаваючої області").

Ціль моделювання (Purpose).Основою проектування є системний підхід, що визначає сувору залежність цілей і задач проектування моделі. Модель не може бути побудована без чітко сформульованої мети. Мета повинна визначати предметну область проектування, задачі проектування, результати проектування. Формулювання цілі дозволяє групі аналітиків фокусувати зусилля в потрібному напрямі. Прикладами формулювання мети можуть бути наступні твердження: "Ідентифікувати і визначити поточні проблеми об'єкту управління (аналізованого об'єкту), зробити можливим аналіз потенційних поліпшень", "Визначити найбільш витратні підрозділи підприємства", "Описати організаційно-функціональну структуру підприємства з метою подальшої розробки інформаційної системи" і т.д.

Точка зору (Point view).При побудові моделі враховують думки різних фахівців, однак модель повинна будуватися згідно єдиної точки зору. Точку зору можна уявити як певний аспект моделювання. Слід зазначити, що точка зору повинна відповідати цілі моделювання. Очевидно, що опис роботи підприємства з погляду фінансиста і технолога виглядає по-різному, тому протягом процесу моделювання важливо виробити єдину точку зору. Як правило, вибирається точка зору фахівця, відповідального за процес моделювання. При виборі точки зору на модель важливим є документування альтернативних моделей, представлень предметної області. Для цієї цілі звичайно використовують діаграми (IDEF0, IDEF3).

IDEF0 модель припускає наявність чітко сформульованої мети єдиного суб'єкта моделювання і однієї точки зору. Для визначення області, цілі і точки зору в моделі IDEF0 у ВРwin слід вибрати пункт меню Model Properties, що викликає діалог Model Properties. У вкладку Рurроsе даного діалогу слід внести ціль і точку зору, а у вкладку Definition – визначення моделі і опис області.

У вкладці Status того ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний і т.д.), час створення і останнього редагування (відстежується надалі автоматично по системній даті). У вкладці Source описуються джерела інформації для побудови моделі (наприклад, "Опитування експертів предметної області і аналіз документації"). Вкладка General служить для внесення назви проекту і моделі, прізвища і ініціалів автора і тимчасових рамок моделей АS-IS і ТО-ВЕ.

Модель може містити чотири типи діаграм:

контекстна діаграма (у кожній моделі може бути лише одна контекстна діаграма);

діаграма декомпозиції;

діаграма дерева вузлів;

діаграма для експозиції (Note).

Контекстна діаграма є вершиною деревовидної структури діаграм і є найзагальнішим описом системи і її взаємодії з зовнішнім середовищем. Після опису системи в цілому проводиться розбиття її на фрагменти. Цей процес називається функціональною декомпозицією, а діаграми, які описують кожен фрагмент і взаємодію фрагментів, називаються діаграмами декомпозиції. Після декомпозиції контекстної діаграми проводиться декомпозиція кожного фрагмента системи на дрібніші і т.д., до досягнення потрібного рівня деталізації опису. Після кожного сеансу декомпозиції проводиться експертиза – експерти предметної області визначають відповідність реальних процесів бізнесу створеним діаграмам. Знайдені невідповідності виправляються, і здійснюється перехід до наступного рівня декомпозиції. Дана процедура дозволяє досягти відповідність моделі реальним процесам бізнесу на будь-якому рівні моделі. Синтаксис опису системи в цілому і кожного її фрагмента однаковий у всій моделі.