Вступ Створення моделі процесів в Bpwin

Зміст
Вступ .................................................................................................................................... 4 1 Створення моделі процесів в Bpwin ........................................................................ 5 1.1 Концепція IDEF0 ................................................................................................. 6 1.1.1 Роботи (Activity) .......................................................................................... 7 1.1.2 Стрілки (Arrow) ............................................................................................ 9 1.1.3 Діаграми дерева вузлів .............................................................................. 12 1.1.4 Вартісний аналіз (ABC) ............................................................................ 12 1.1.5 Рекомендації по малюванню діаграм ..................................................... 14 1.2 DFD – діаграми потоків даних ........................................................................ 14 1.2.1 Роботи .......................................................................................................... 16 1.2.2 Зовнішні сутності ....................................................................................... 16 1.2.3 Стрілки (потоки даних) ............................................................................. 16 1.2.4 Сховища даних ........................................................................................... 17 1.2.5 Нумерація об'єктів ...................................................................................... 18 1.3 Метод опису процесів IDEF3 .......................................................................... 18 1.3.1 Одиниці роботи - Unit of Work (UOW) .................................................. 19 1.3.2 Зв'язки .......................................................................................................... 19 1.3.3 Об'єкт посилання ....................................................................................... 20 2 Створення моделі даних за допомогою Erwin ..................................................... 22 2.1 Палітра інструментів в Erwin .......................................................................... 22 2.2 Створення логічної моделі даних ................................................................... 23 2.2.1 Рівні логічної моделі ................................................................................. 23 2.2.2 Сутності та атрибути ................................................................................. 23 2.2.3 Зв'язки .......................................................................................................... 25 2.2.4 Ієрархія спадкоємства (або ієрархія категорій) .................................... 27 3 Завдання до лабораторних робіт ............................................................................ 30
Додаток 1 Структура ІС ............................................................................................. 34
Додаток 2 Методологія IDEF0 ................................................................................... 35

3 1. Створення моделі процесів життєвого циклу виробу
BPwin є інструментом для створення моделей, що дозволяють аналізувати, документувати і планувати зміни складних процесів в життєвому циклі виробів.
BPwin пропонує засіб для збору всієї необхідної інформації про роботу підприємства та графічного зображення цієї інформації у вигляді цілісної моделі.
BPwin підтримує три таких методології: IDEF0, DFD і IDEF3, що дозволяють аналізувати життєвий цикл виробу з трьох ключових точок зору:
З погляду функціональності системи. В рамках методології IDEF0
(Integration Definition for Function Modeling) процес представляється у вигляді набору елементів-робіт, які взаємодіють між собою, а також відтворює
інформаційні, людські та виробничі ресурси, що використовуються на кожному етапі життєвого циклу.
Діаграми DFD (Data Flow Diagramming) описують потоки даних, дозволяючи прослідкувати, яким чином відбувається обмін інформацією між - функціями усередині системи. У той же час діаграми DFD залишають без уваги взаємодії між бізнес-функціями.
Ще точнішу картину можна отримати, доповнивши модель діаграмами
IDEF3, яка відображає черговість виконання подій. У IDEF3 включені елементи логіки, що дозволяє моделювати та аналізувати альтернативні сценарії розвитку процесу.
BPwin має достатньо простий та інтуїтивно зрозумілий інтерфейс користувача, що дає можливість створювати складні моделі при мінімальних зусиллях. При створенні нової моделі з’являється діалог, в якому слід вказати, чи буде створена модель наново або відкрита з файлу. Для створення нової моделі необхідно внести ім'я моделі і вибрати методологію, в якій буде побудована модель (рис.1).

4
Рис.1 Діалог створення моделі
1.1 Концепція IDEF0
Найбільш зручною мовою моделювання процесів є IDEF0, де система представляється як сукупність взаємодіючих робіт і функцій.
Така чисто функціональна орієнтація є принциповою – функції системи аналізуються незалежно від об'єктів, якими вони оперують. Це дозволяє чітко моделювати логіку і взаємодію процесів організації.
Результатом застосування методології
є модель, побудована зі сформульованою метою та з єдиною точкою зору, яка складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми – головні компоненти моделі, всі функції та інтерфейси на них представлені як блоки і стрілки.
Мета моделювання (Purpose). Модель не може бути побудована без чітко сформульованої мети. Мета повинна відповідати на наступні питання:
Чому цей процес повинен бути змодельований?
Що повинна показати модель?

5
Прикладом формулювання мети може служити наступне твердження:
"Описати функціонування виробництво з виготовлення приладу".
Точка зору (Viewpoint). Точку зору можна показати як погляд людини, яка бачить систему в потрібному для моделювання аспекті. Точка зору повинна відповідати меті моделювання. Наприклад, “Конструктор”.
Для внесення мети і точки зору в моделі IDEF0 в Bpwin слід вибрати пункт меню Model/Model Properties, що викликає діалог Model Properties. У закладці
Purpose слід внести мету і точку зору, а в закладку Definition – визначення моделі
(наприклад, “Бізнес-процеси оборотів МТЦ на складі підприємства при виконанні повсякденної діяльності”) і опис області (наприклад, “Виробничий облік”). У закладці Status того ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний і т.д.). У закладці Source описуються джерела інформації для побудови моделі (Наприклад, “Опитування експертів в даній області й аналіз документації”). Закладка General служить для внесення назви проекту і моделі,
імені та ініціалів автора і тимчасових рамок моделі - AS-IS (як є) і TO-BE (як повинно бути).
Результат опису моделі можна отримати в звіті Model Report. Діалог настройки звіту викликається з пункту меню Tools/Report/Model Report. У діалозі настройки слід вибрати необхідні поля, при цьому автоматично відображається черговість виведення інформації в звіт.
1.1.1 Роботи (Activity)
Роботи позначають поіменовані процеси, функції або завдання, які відбуваються протягом певного часу і мають розпізнавані результати.
Роботи на діаграмах зображаються прямокутниками. Блок представляє функцію або активну частину системи, тому назвами блоків служать дієслова або сполучення дієслів (наприклад, "виготовлення виробу" або "виготовити виріб").

6
При створенні нової моделі автоматично створюється контекстна діаграма з
єдиною роботою, що зображає систему в цілому (рис.2). Для внесення імені роботи слід клацнути по роботі правою кнопкою миші
, вибрати в меню
Name і в діалоговому вікні, що з'явилося, внести назву роботи. Для опису інших властивостей роботи служить діалог Activity Properties. Вміст словника робіт можна роздрукувати у вигляді звіту (меню Tools/Report/Diagram Object Report).
Рис.2 Приклад контекстної діаграми
Діаграми декомпозиції містять дочірні роботи. Для створення діаграми декомпозиції слід клацнути по кнопці:
З’являється діалог Activity Box Count, в якому слід вказати нотацію нової діаграми і кількість робіт на ній. Для забезпечення наочності і кращого розуміння модельованих процесів рекомендується використовувати від трьох до шести блоків на одній діаграмі. Якщо виявилось, що кількості робіт недостатньо, то роботу можна додати в діаграму, клацнувши спочатку по кнопці на палітрі
інструментів, а потім у вільне місце на діаграмі.
Роботи ніколи не розміщуються на діаграмі випадковим чином. Вони розміщуються по ступеню важливості, як її розуміє автор діаграми. Цей відносний порядок називається домінуванням. Найбільш домінуючий блок зазвичай розміщується у верхньому лівому кутку діаграми, а найменше домінуючий – в правому нижньому кутку. В результаті виходить "ступінчаста" схема.

7
Порядок домінування може позначатися цифрою, розміщеною в правому нижньому кутку кожного прямокутника: А1 указуватиме на найбільше домінування, А2 – на наступне після найбільшого, і т.д. Блок будь-якої діаграми може бути далі описаний діаграмою нижнього рівня, яка, у свою чергу, може бути далі деталізована за допомогою необхідного числа діаграм. Таким чином, формується ієрархія діаграм (рис.3).
Загальне представлення
Детальне представлення
Ця діаграма є «батьком» цієї діаграми
Рис.3 Ієрархія діаграм
1.1.2 Стрілки (Arrow)
Взаємодія робіт між собою і зовнішнім світом описується у вигляді стрілок.
Стрілки є якоюсь інформацією та іменуються іменниками (наприклад, сировина).
У IDEF0 розрізняють п'ять типів стрілок (рисунок 4):
Вхід (Input) – матеріал або інформація, які використовуються або перетворяться роботою для отримання результату (виходу). Допускається, що

8 робота може не мати жодної стрілки входу. Стрілка входу малюється як вхідна в ліву грань роботи.
Управління (Control) – правила, стратегії, процедури або стандарти, якими керується робота. Кожна робота повинна мати хоч би одну стрілку управління.
Стрілка управління малюється якщо входить у верхню грань роботи.
Вихід (Output) – матеріал або інформація, які виробляються роботою. Кожна робота повинна мати хоч би одну стрілку виходу. Робота без результату не має сенсу і не повинна моделюватися. Стрілка виходу малюється як вихідна з правої грані роботи.
Механізм (Mechanism) – ресурси, які виконують роботу. Стрілка механізму малюється як вхідна в нижню грань роботи.
Виклик (Call) – спеціальна стрілка, що вказує на іншу модель роботи. Стрілка виклику малюється як витікаюча з нижньої грані роботи.
Рис. 4 Функціональний блок і інтерфейсні стрілки
Взаємодія між блоками зображається стрілками. Існує п'ять видів взаємозв'язків між блоками:

9
Вихід - Вхід (output - input). Вихід одного блоку є входом іншого. Зв'язок по вхідному зворотному зв'язку має місце тоді, коли вихід одного блоку стає входом
іншого блоку з великим домінуванням.
Вихід - Управління (output - control). Вихід одного блоку є дією, що управляє, іншим.
Вихід - Механізм (output - mechanism). Вихід одного блоку є засобом
іншого.
Вихід - Механізм - Зворотний зв'язок (output - mechanism- feedback).
Вихід - Управління - Зворотний зв'язок (output - control - feedback).
Зворотний зв'язок по управлінню виникає тоді, коли вихід деякого блоку впливає на блок з великим домінуванням. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень тощо (рис.5).
Рис.5 Приклад зворотного зв'язку
Стрілки в IDEF0, як правило, зображають набори предметів, тому вони можуть розгалужуватися і з'єднуватися разом різним чином. Розгалуження стрілки означають, що частина її вмісту (або весь набір предметів) може з'явитися в кожному відгалуженні стрілки. Стрілка завжди позначається до розгалуження, щоб дати назву всьому набору. Крім того, кожне відгалуження стрілки може бути

10 помічене відповідно до наступних правил: вважається, що непомічена гілка містить всі предмети, вказані в мітці перед розгалуженням; кожна мітка гілки уточнює, що саме містить ця гілка. Злиття стрілок указує, що вміст кожної гілки бере участь у формуванні після злиття об'єднаної стрілки. Після злиття стрілка завжди позначається для вказівки нового набору, крім того, кожна гілка перед злиттям може позначатися відповідно до наступних правил: вважається, що непомічені гілки містять всі предмети, вказані в загальній мітці після злиття; кожна мітка уточнює, що саме містить ця гілка.
Для внесення на діаграму стрілки необхідно клацнути по кнопці з символом стрілки в палітрі інструментів перенести курсор до лівої сторони екрану, поки не з'явиться початкова штрихова смужка; клацнути один раз по смужці (звідки виходить стрілка) і ще раз в лівій частині роботи з боку входу (де закінчується стрілка); повернутися в палітру інструментів і вибрати опцію редагування стрілки клацнути правою кнопкою миші на лінії стрілки, в спливаючому меню вибрати
Name Editor і додати ім'я стрілки в закладці Name, у вкладці Definition занести визначення стрілки і додатковий опис. Також можна змінити стиль, розмір шрифту і колір стрілки.
Вміст словника стрілок можна роздрукувати у вигляді звіту (меню
Tools/Report/Arrow Report.) і отримати тим самим тлумачний словник термінів предметної області, що використовуються в моделі.
1.1.3 Діаграми дерева вузлів
Діаграма дерева вузлів показує ієрархію робіт в моделі і дозволяє розглянути всю модель цілком, але не показує взаємозв'язку між роботами
(стрілки). Для створення діаграми дерева вузлів слід вибрати в меню пункт
Diagram/Node Tree. У діалозі Node Tree слід вказати глибину дерева - Number of

11
Levels (за умовчанням 3) і корінь дерева (за умовчанням - батьківська робота поточної діаграми). За умовчанням нижній рівень декомпозиції показується у вигляді списку, решта робіт – у вигляді прямокутників. Для відображення всього дерева у вигляді прямокутників слід вимкнути опцію Bullet Last Level. При створенні дерева вузлів необхідно вказати назву діаграми.
1.1.4 Вартісний аналіз (ABC)
Вбудований в BPwin механізм обчислення вартості дозволяє оцінювати і аналізувати витрати на здійснення різних видів ділової активності. Механізм обчислення витрат на основі виконуваних дій (Activity-Based Costing, ABC) – це технологія, що застосовується для оцінки витрат і використовуваних ресурсів. Вона допомагає розпізнати
і виділити найбільш дорогі операції для подальшого аналізу. ABC є широко поширеною методикою, використовуваною міжнародними корпораціями і державними організаціями
(зокрема Департаментом оборони США) для ідентифікації дійсних рушіїв витрат в організації. Вартісний аналіз є угода про облік, використовувана для збору витрат, пов'язаних з роботами, з метою визначити загальну вартість процесу. Вартісний аналіз заснований на моделі робіт, оскільки кількісна оцінка неможлива без детального розуміння функціональності підприємства. Зазвичай ABC застосовується для того, щоб зрозуміти походження вихідних витрат і полегшити вибір потрібної моделі робіт при реорганізації діяльності підприємства.

12
Рис.6 Діалог Cost Center Editor
При проведенні вартісного аналізу спочатку задаються одиниці вимірювання часу і грошей. Для задання одиниць вимірювання слід викликати діалог Model Properties (меню Model/Model Properties), закладка ABC Units. Якщо в списку вибору відсутня необхідна валюта, її можна додати. Діапазон вимірювання часу в списку Time Unit достатній для більшості випадків – від секунд до років. Потім описується центр витрат (cost centers). Для внесення центрів витрат необхідно викликати діалог Cost Center Editor (меню Model/Cost
Center Editor). Кожному центру витрат слід дати докладний опис у вікні Definition
(рис.6).
Для задання вартості робіт (для кожної роботи на діаграмі дерева композиції) слід клацнути правою кнопкою миші по роботі і на спливаючому меню вибрати Cost. У діалозі Cost указується частота проведення даної роботи в рамках загального процесу (вікно Frequency) і тривалість (Duration). Потім слід вибрати в списку один з центрів витрат і у вікні Cost задати його вартість.
Аналогічно призначаються суми по кожному центру витрат, тобто задається вартість кожної роботи по кожній статті витрати. Загальні витрати по роботі розраховуються як сума по всіх центрах витрат. При обчисленні витрат поточної

13 роботи спочатку обчислюється добуток витрат дочірньої роботи на частоту робіт, потім результати додаються. Якщо у всіх роботах моделі включений режим
Compute from Decompositions, подібні обчислення автоматично проводяться за всією ієрархією робіт від низу до верху. Це достатньо спрощений принцип підрахунку справедливий, якщо роботи виконуються послідовно. Якщо схема виконується складніша (наприклад, роботи виконуються альтернативно), можна відмовитися від підрахунку і задати підсумкові суми для кожної роботи уручну
(Override Decompositions). В цьому випадку результати розрахунків з нижніх рівнів декомпозиції ігноруватимуться, при розрахунках на верхніх рівнях враховуватиметься сума, задана вручну. На будь-якому рівні результати розрахунків зберігаються незалежно від вибраного режиму, тому при виключенні опції Override Decompositions розрахунок від низу до верху проводиться звичайним способом.
Результати вартісного аналізу наочно представляються на спеціальному звіті
– Activity Cost Report (меню Tools/Report/ Activity Cost Report).
1.1.5 Рекомендації по створенню діаграм
У реальних діаграмах до кожної роботи може підходити і від кожної може відходжувати близько десятка стрілок. Якщо діаграма містить 6-8 робіт, то вона може містити 30-40 стрілок, причому вони можуть зливатися, розгалужуватися і перетинатися. Такі діаграми можуть дуже погано читатися. У IDEF0 існують правила по малюванню діаграм. Деякі з цих правил BPwin підтримує автоматично, виконання інших слід забезпечити уручну.

14
Прямокутники робіт повинні розташовуватися по діагоналі з лівого верхнього в правий нижній кут (порядок домінування);
Слід максимально збільшити відстань між вхідними або вихідними стрілками на одній грані роботи;
Зворотні зв'язки по входу малюються “нижньою” петлею, зворотний зв'язок по управлінню - “верхньою”;
Слід мінімізувати кількість перетинів, петель і поворотів стрілок.
1.2 DFD – діаграми потоків даних
Діаграми потоків даних (Data Flow Diagramming, DFD) використовуються для опису документообігу і обробки інформації.
DFD описує: функції обробки інформації (роботи);
· документи (стрілки), об'єкти, співробітників або відділи, які беруть участь в обробці інформації;
· зовнішні посилання, які забезпечують інтерфейс із зовнішніми об'єктами, що знаходяться за межею модельованої системи;
· таблиці для зберігання документів (сховища даних).
Модель системи визначається як ієрархія діаграм потоків даних, що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії визначають основні процеси із зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція продовжується, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому операції стають елементарними і проводити декомпозицію
їх далі неможливо.
Джерела інформації (зовнішні сутності) породжують інформаційні потоки
(потоки даних), що переносять інформацію до підсистем або процесів. Ті у свою

15 чергу перетворюють інформацію і породжують нові потоки, які переносять
інформацію до інших процесів або підсистем, накопичувачів даних або зовнішньої сутності – споживачів інформації.
На відміну від стрілок IDEF0, які є жорсткими взаємозв'язками, стрілки DFD показують, як об'єкти (включаючи дані) рухаються від однієї роботи до іншої. Це представлення потоків сумісне з сховищами даних і зовнішніми сутностями робить моделі DFD більш схожими на фізичні характеристики системи – рух об'єктів, зберігання об'єктів, постачання і розповсюдження об'єктів.
На відміну від IDEF0, де система розглядається як взаємозв'язані роботи,
DFD розглядає систему як сукупність предметів.
Таким чином, основними компонентами діаграм потоків даних є: роботи;
· зовнішні сутності;
· стрілки (потоки даних);
· сховище даних.
Для того, щоб доповнити модель IDEF0 діаграмою DFD потрібно в процесі декомпозиції в діалозі Activity Box Count клацнути по радіокнопці DFD. У палітрі
інструментів на новій діаграмі DFD з'являються нові кнопки: додати в діаграму зовнішнє посилання; додати в діаграму сховище даних.

16
1.2.1 Роботи
На DFD роботи представляють функції системи, що перетворюють входи у виходи. Роботи зображаються прямокутниками із заокругленими кутами. Їх сенс співпадає з сенсом робіт IDEF0, вони також мають входи і виходи, але не підтримують управління і механізми.
1.2.2 Зовнішні сутності
Зовнішні сутності зображають входи в систему і/або виходи з системи.
Зовнішня сутність є матеріальним предметом або фізичною особою, що є джерелом або приймачем інформації. Визначення деякого об'єкту або системи як зовнішньої сутності вказує на те, що вона знаходиться за межами аналізованої ІС. В процесі аналізу деяка зовнішня сутність може бути перенесена всередину діаграми аналізованої ІС, якщо це необхідно, або, навпаки, частина процесів ІС може бути винесена за межі діаграми і представлена як зовнішня сутність.
Рис. 7 Зовнішня сутність
Зовнішні сутності зображаються у вигляді прямокутника з тінню і зазвичай розташовуються по краях діаграми (рис.7). Одна зовнішня сутність може бути використана багато разів на одній або декількох діаграмах. Зазвичай такий прийом використовують, щоб не малювати дуже довгих і заплутаних стрілок.
1.2.3 Стрілки (потоки даних)
Стрілки описують рух об'єктів з однієї частини системи в іншу. Оскільки в
DFD кожна сторона роботи не має чіткого призначення, як в IDEF0, стрілки

17 можуть підходити і виходити з будь-якої грані прямокутника роботи. Кожен потік даних має ім'я, зміст, що відображає його (рис.8).
Рис.8 Потік даних
У DFD застосовуються двонаправлені стрілки для опису діалогів типу
«команда - відповідь» між роботами, між роботою і зовнішньою сутністю і між зовнішніми сутностями (рис.9).
Рис.9 Діалог типу "команда-відповідь" (контекстна діаграма)
У DFD стрілки можуть зливатися і розгалужуватися, що дозволяє описувати декомпозицію стрілок. Кожен новий сегмент стрілки, що зливається і розгалужується, може мати своє власне ім'я.
1.2.4 Сховища даних
На відміну від стрілок, що описують об'єкти в русі, сховища даних зображають об'єкти у спокої. Сховища даних можуть бути реалізовані фізично у вигляді ящика в картотеці, таблиці в оперативній пам'яті, файлу на магнітному носієві і т.д. Сховища даних на діаграмі потоків даних зображаються, як показано на малюнку 10.

18
Рис.10 Накопичувач даних
У матеріальних системах сховища даних зображаються там, де об'єкти чекають обробки, наприклад в черзі. У системах обробки інформації сховища даних є механізмом, який дозволяє зберегти дані для подальших процесів. Ім'я накопичувача вибирається з міркування найбільшої інформативності для проектувальника.
1.2.5 Нумерація об'єктів
У DFD номер кожної роботи може включати префікс, номер батьківської роботи (А) і номер об'єкту. Номер об'єкту – це унікальний номер роботи на діаграмі.
Унікальний номер мають сховища даних і зовнішні сутності не залежно від їх розташування на діаграмі. Кожне сховище даних має префікс D і унікальний номер, наприклад D5. Кожна зовнішня сутність має префікс E і унікальний номер, наприклад E5.
1.3 Метод опису процесів IDEF3
Діаграми IDEF3 можуть бути використані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації. Під сценарієм розумітимемо послідовність ситуацій або дій, які описують типовий клас проблем, присутніх в організації або системі, опис послідовності властивостей об'єкту, в рамках даного процесу (наприклад, послідовність обробки замовлення).
IDEF3 представляє інструментарій для наочного дослідження і моделювання сценаріїв виконання процесів. Метод дозволяє проводити опис з необхідним

19 ступенем деталізації за допомогою використання декомпозиції. IDEF3 як інструмент моделювання фіксує наступну інформацію про процес:
· об'єкти, які беруть участь при виконанні сценарію;
· ролі, які виконують ці об'єкти (наприклад, агент, транспорт і т.д.);
· відносини між працівниками в ході виконання сценарію процесу;
· стани і зміни, яким піддаються об'єкти;
· час виконання і контрольні точки синхронізації робіт;
· ресурси, які необхідні для виконання робіт.
Кожна робота в IDEF3 описує який-небудь сценарій бізнес-процесу і може бути складовою іншої роботи. Оскільки сценарій описує мету і рамки моделі, важливо, щоб роботи іменувалися дієслівним іменникам, що означають процес дії, або фразою що містить такий іменник.
Точка зору на модель повинна бути задокументована. Звичайно це точка зору людини, відповідальної за роботу в цілому.
Також необхідно задокументувати мету моделі – ті питання, на які покликана відповісти модель.

20
1.3.1 Одиниці роботи – Unit of Work (UOW)
UOW, які також називаються роботами, є центральними компонентами моделі. У IDEF3 роботи зображаються прямокутниками з прямими кутами і мають назви, що позначають процес дії, і номер (ідентифікатор); інший іменник у складі тієї ж фрази зазвичай відображає основний вихід (результат) роботи (наприклад,
«Виготовлення виробу»). Зазвичай номер роботи складається з номера батьківської роботи і порядкового номера на поточній діаграмі.
1.3.2 Зв'язки
Зв'язки показують взаємовідношення робіт. Всі зв'язки в IDEF3 однонаправлені і можуть бути направлені куди завгодно, але зазвичай діаграми
IDEF3 прагнуть побудувати так, щоб зв'язки були направлені зліва направо. У
IDEF3 розрізняють три типи стрілок, що зображають зв'язки, стиль яких встановлюється через меню Model/Default Arrow Types:
Старша (Precedence) – суцільна лінія, що зв'язує одиниці робіт. Малюється зліва направо або зверху вниз. Показує що робота-джерело повинна закінчитися перш, ніж робота-мета почнеться.
Відношення (Relational Link) – пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (робота-мета починається, коли робота- джерело ще не закінчилася), а так само між одиницями робіт і об'єктами посилань.
Потоки об'єктів (Object Flow) – стрілка з двома наконечниками, застосовується для опису того факту, що об'єкт використовується в двох або більше одиницях роботи, наприклад, коли об'єкт породжується в одній роботі і використовується в іншій.
Старший зв'язок і потік об'єктів. Старший зв'язок показує, що робота- джерело закінчується раніше, ніж починається робота-мета. Часто результатом роботи-джерела стає об'єкт, необхідний для запуску роботи-мети. В цьому

21 випадку стрілку, що позначає об'єкт, зображають з подвійним наконечником. Ім'я стрілки повинно ясно ідентифікувати об'єкт, що відображається. Потік об'єктів має ту ж семантику, що і старша стрілка.
Відношення показує, що стрілка є альтернативою старшій стрілці або потоку об'єктів в сенсі задання послідовності виконання робіт – робота-джерело не обов'язково повинна закінчитися, перш ніж робота-мета почнеться . Більш того, робота-мета може закінчитися перш, ніж закінчитися робота-джерело.
Перехрестя (Junction). Закінчення однієї роботи може служити сигналом до початку декількох робіт, або ж одна робота для свого запуску може чекати закінчення декількох робіт. Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи.
Розрізняють перехрестя для злиття (Fan-in Junction) і розгалуження (Fan-out
Junction) стрілок. Перехрестя не може одночасно використовуватися для злиття і розгалуження. У діалозі Select Junction Type указується тип перехрестя.
Розрізняють декілька типів перехресть (таблиця 1). Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J. Можна редагувати властивості перехрестя за допомогою діалогу Definition Editor. На відміну від IDEF0 і DFD в
IDEF3 стрілки можуть зливатися або розгалужуватися тільки через перехрестя.
Таблиця 1
Назва
Зміст у випадку злиття стрілок
(Fan-in Junction)
Зміст у випадку розгалуження стрілок (Fan- out Junction)
Asynchronous
(AND)
Всі процеси, що були перед тим повинні бути завершені
Всі наступні процеси повинні бути розпочаті
Synchronous
(AND)
Всі процеси, що були перед тим повинні бути завершені одночасно
Всі наступні процеси повинні бути розпочаті одночасно

22
Asynchronous
(OR)
Один чи декілька процесів, що були перед тим повинні бути завершені
Один чи декілька наступних процесів повинні бути розпочаті
Synchronous
(OR)
Один чи декілька процесів, що були перед тим завершені одночасно
Один чи декілька наступних процесів розпочаті одночасно
XOR
(Exclusive OR)
Тільки один процес, що був перед тим завершений
Один наступний процес розпочатий
1.3.3 Об'єкт посилання
Об'єкт посилання в IDEF3 виражає якусь ідею, концепцію або дані, які не можна пов'язати із стрілкою, перехрестям або роботою (рис.11). Для внесення об'єкту посилання використовується служить кнопка в палітрі інструментів
Об'єкт посилання зображається у вигляді прямокутника, схожого на прямокутник роботи. Як ім'я можна використовувати ім'я якої-небудь стрілки з
інших діаграм або ім'я сутності з моделі даних. Об'єкти посилання повинні бути пов'язані з одиницями робіт або перехрестями пунктирними лініями.
Рис.11 Об'єкт посилання
Офіційна специфікація IDEF3 розрізняє три стилі об'єктів посилань – безумовні (unconditional), синхронні (Synchronous) і асинхронні (Asynchronous).

23
BPwin підтримує тільки безумовні об'єкти посилань. Синхронні і асинхронні об'єкти посилань, використовувані на діаграмах переходів станів об'єктів, не підтримуються. При внесенні об'єктів посилань крім імені слід указувати тип об'єкту посилання (таблиця 2).
Таблиця 2
Тип об'єкту посилання
Мета опису
OBJECT
Описує участь важливого об'єкту в роботі
GOTO
Інструмент циклічного переходу (у послідовності робіт, що повторюється), можливо на поточній діаграмі, але необов'язково. Якщо всі роботи циклу присутні на поточній діаграмі, цикл може також зображатися стрілкою що повертається на стартову роботу.
UOB (Unit of behavior)
Застосовується коли необхідно підкреслити множинне використання якої-небудь роботи, але без циклу. Наприклад, робота «Контроль якості» може бути використаний в процесі
«Виготовлення виробу» кілька разів, після кожної одиничної операції. Зазвичай цей тип посилання не використовується для моделювання робіт, що автоматично запускаються.
NOTE
Використовується для документування важливої інформації, що відноситься до яких-небудь графічних об'єктів на діаграмі.
ELAB
(Elaboratio n)
Використовується для удосконалення графіків або
їх детального опису. Зазвичай уживається для детального опису розгалуження і злиття стрілок на перехрестях.

30
Література
1. Вендров А.М. CASE – технологии. Современные методы и средства проектирования информационных систем. – ИТМО, http://cs.ifmo.ru/win/education/documentation/case/index/shtml
2. Маклаков С.В. "BPwin, ERwin. CASE-средства разработки информационных систем." М:Диалог-МИФИ, 1999 г.
3. Окулесский В.А. "Функциональное моделирование – методологическая основа реализации процессного подхода". НИЦ "Прикладная логистика".
4. Типовой СТП. CALS – технологии. Моделирование процессов предприятия с использованием методологии IDEF0. – НИЦ CALS – технологии: «Прикладная логистика»,2001.