2.3.5 Розгалуження і сполучення моделей

Розгалуження моделей в BPWin використовується, як правило, для підтримки колективної розробки моделей. Єдина модель може бути розділена на частини, щоб дозволити кільком розробникам створювати власні функціональні блоки моделі. Після завершення розробки розділена на частини модель може бути об’єднана в одну для відображення бізнес процесу в цілому. При розгалуженні моделей на дві кожна із них підтримує власний набір функціональних блоків, стрілок та інших об’єктів BPWin.

Розгалуження моделі. Для розгалуження моделі на частини необхідно притримуватися наступного алгоритму:

• визначте частину моделі, яку необхідно відділити;

• клацніть правою клавішею миші на вибраному функціональному блоці;

• виберіть пункт меню Split Model;

• в діалоговому вікні Split Options введіть ім’я, яке відповідає імені функціонального блоку (використання цього блоку в подальшому дозволить об’єднати модель);

• включіть опцію Copy entire dictionaries, щоб зкопіювати словники об’єктів в частину моделі, що відділяється;

• натисніть кнопку OK.

В дереві моделі буде створена і відображена нова модель. Зверніть увагу на наступні моменти:

• блок, з якого виконувалося розгалуження, стає діаграмою контекстного рівня в новій моделі;

• у вихідному зв’язку з’являється стрілка з іменем, яке відповідає імені нової моделі;

• всі дочірні діаграми функціонального блоку перенесені в нову модель;

• розбитий функціональний блок залишається у вихідній моделі.

Сполучення моделей. Після завершення розробки розділених моделей BPWin дозволяє їх сполучення в одну. Для сполучення моделей:

• назва стрілки зв’язку повинна відповідати назві моделі, що імпортується;

• назва функціонального блоку в контекстній діаграмі моделі, що імпортується, повинна відповідати назві аналогічного функціонльного блоку в основній моделі.

При сполученні BPWin копіює всі функціональні блоки, стрілки та іншу інформацію (крім контекстної діаграми) із моделі, що імпортується, в основну. BPWin пропускає діаграму контекстного рівня в моделі, що імпортується, оскільки вона вже існує в основній моделі. Всі декомпозиції в моделі, що імпортується, відносяться в основній моделі до цільового функціонального блоку. Цільовий функціональний блок в основній моделі завжди повинен мати стрілку зв’язку, що виходить із нього.

Після відкриття основної моделі і моделі, що імпортується, потрібно:

• клацнути правою клавішею миші на функціональному блоці основної моделі, до якого потрібно імпортувати дані;

• вибрати із меню пункт Merge Model;

• діалог Continue with merge? підтверджує, що саме Ви хочете об’єднати, і дозволяє задати опції сполучення.

Після завершення сполучення можна помітити, що дерево моделі обновлюється для відображення змін в основній моделі.

2.3.6 Межі моделювання

Одним з позитивних результатів побудови функціональних моделей виявляється прояснення меж моделювання системи в цілому і її основних компонентів. Хоч і передбачається, що в процесі роботи над моделлю відбуватиметься деяка зміна меж моделювання, їх вербальний (словесний) опис повинний підтримуватися із самого початку для забезпечення координації роботи аналітиків, що беруть участь в проекті. Як і при визначенні цілі моделювання, відсутність меж утрудняє оцінку ступеня завершеності моделі, оскільки межі моделювання мають тенденцію до розширення із зростанням розмірів моделі.

Межі моделювання мають два компоненти: ширину обхвату і глибину деталізації. Ширина обхвату позначає зовнішні межі модельованої системи. Глибина деталізації визначає ступінь подробиці, з якою потрібно проводити декомпозицію функціональних блоків.

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

Коли межі моделювання зрозумілі, стають ясними і причини, по яких деякі об'єкти системи не увійшли до моделі.