++all Fussion - Labs - 2022 (8)

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРС ИТЕТ „ЛЬВІВСЬКА ПОЛІ ТЕХНІКА”
МЕТОДИЧНІ ВКАЗІВКИ
ДЛЯ ВИКОНАННЯ ЛАБОРАТОРНИХ РОБІТ З ДИСЦИПЛІНИ:
“МЕТОДОЛОГІЇ СИСТЕМНОГО АНАЛІЗУ”
Львів - 2022
Методичні вказівки для виконання лабораторних робіт з курсу
“Методології системного аналізу ”
Укладач: Басюк Т. М., к.т.н., доцент каф. ІСМ
ВИМОГИ ДО ОФОРМЛЕННЯ ЗВІТІВ ПРО ВИКОНАННЯ

ЛАБОРАТОРНИХ РОБІТ
Звіти про виконання лабораторних робіт оформляються на зшитих аркушах
формату А4. Після захисту лабораторних робіт звіти здаються для зберігання на
кафедру. Кожен звіт повинен містити такі розділи:
• Номер та назва роботи;
• Мета виконання лабораторної роботи;
• Індивідуальне завдання з детальним формулюванням розв’язуваної задачі,
використовувані (власні) теоретичні відомості;
• Відповіді на контрольні запитання
• Деталізований опис кожного з пунктів порядку виконання роботи
• Висновки. Вказується призначення роботи, можливі варіанти вдосконалення
та які знання отримано в ході виконання роботи.
Звіт повинен бути написаний українською мовою, акуратно та грамотно, з
дотриманням правил оформлення ділової документації. Назви розділів звіту
візуально виділити розміром, підкресленням.
2
Лабораторна робота №1.
Інструментальне середовище AllFusion Process Modeler. Побудова моделі в
стандарті IDEF0
Мета роботи – ознайомитись з основними принципами проектування

інтегрованих систем та вивчити інтерфейс програми AllFusion Process Modeler
(BPwin) та побудувати модель предметної області в стандарті IDEF0.
Теоретичні відомості.
AllFusion Process Modeler (BPwin) – CASE-засіб для моделювання бізнес-
процесів, що дозволяє створювати діаграми в нотації IDEF0, IDEF3, DFD. В
процесі моделювання програмний засіб дозволяє перемикатися з нотації IDEF0
на будь-якій гілці моделі на нотацію IDEF3 або DFD і створити змішану модель.
BPwin підтримує функціонально-вартісний аналіз. Функціонально-вартісний
аналіз (ФВА, Activity Based Costing, АВС) – метод визначення вартості та інших
характеристик виробів, послуг і споживачів, що використовують як основи
функції та ресурси, задіяні у виробництві, маркетингу, продажу, доставці,
технічній підтримці, наданні послуг, обслуговуванні клієнтів, а також
забезпечення якості. Метод ФВА розроблений як "операційно-орієнтована"
альтернатива традиційним фінансовим підходам. Зокрема, на відміну від
традиційних фінансових підходів метод ФВА: надає інформацію у формі,
зрозумілій для персоналу підприємства, безпосередньо бере участь у бізнес-
процесі; розподіляє накладні витрати відповідно до детального розрахунку
використання ресурсів. Метою створення ФВА-моделі є вдосконалення
діяльності підприємства за показниками вартості, трудомісткості та
продуктивності. Проведення розрахунків з ФВА-моделі дозволяє отримати
великий обсяг ФВА-інформації з метою підтримки прийняття рішення.
При створенні нової моделі виникає діалог, в якому необхідно вказати, чи
буде створена модель з початку або завантажена з файлу, або зі сховища
ModelMart (рис.1.1а). Від вибору типу моделі залежить в яких нотаціях можна
проводити декомпозицію робіт. Якщо вибрати тип Business Process (IDEF0), то
в створеній моделі можна проводити декомпозицію в нотаціях IDEF0, IDEF3 і
DFD; якщо вибраний тип Data Flow (DFD) – в нотаціях DFD і IDEF3; якщо ж
вибраний тип Process Flow (IDEF3) – то тільки в нотації IDEF3.
При побудові змішаних моделей склад палітри інструментів автоматично
змінюється. Після клацання по кнопці ОК з'являється діалог Properties for New
Models, в який слід ввести властивості моделі (рис.1.1б):
• General – автор моделі і його ініціали;
• Numbering – формат нумерації процесу та порядок його відображення;
• Display – список елементів відображення на діаграмах;
• Layout – параметри розташування;
3
• ABC Units – одиниці функціонально-вартісного аналізу;
• Page Setup – параметри сторінки;
• Header/Footer – параметри верхнього і нижнього колонтитулу.
Рис.1.1. Створення нової моделі (а) та задання її властивостей (б)

Після редагування властивостей моделі з’являється головне вікно програми
(рис. 1.2), що складається з трьох основних частин: 1 – інспектор моделі (Model
Explorer) – відображає структуру моделі (наявні діаграми і їх ієрархія); 2 –
основна частина – в ній відображаються діаграми, з якими ведеться робота; 3 –
панелі інструментів.
Рис. 1.2. Головне вікно програми
4
В створеній моделі з налаштуваннями за замовчанням некоректно
відображаються ичні символи. Щоб усунути цей недолік, необхідно
відкоригувати використовувані в моделі шрифти. Для цього в меню Model\
Default Fonts необхідно послідовно пройтися за всіма пунктами і у випадному
списку Script поставити значення Кириличний і поставити галочку Change all
occurrences.
Панель інструментів Model Toolbox

Панель інструментів відповідає за створення різних графічних елементів
моделі. Залежно від типу поточної діаграми набір кнопок на ній змінюється.
Табл. 1.1. Призначення кнопок Model Toolbox.
Піктограма Назва Призначення
Pointer Tool Перетворює курсор на стрілку покажчика для
того, щоб можна було виділяти об’єкти
- IDEF0 Activity Box Додавання на діаграму нової діаграми
- DFD Tool
- IDEF3
Precedence Додавання на діаграму нової стрілки.
Arrow Tool
Squiggle Tool Пов’язування назви стрілки із самою стрілкою.
Text Tool Додавання на діаграму тексту.
Diagram Відображення вікна менеджера діаграм для
Dictionary перегляду наявних діаграм по типах і перехід до
Editor вибраної.
Go to Sibling Перехід між стандартною діаграмою, деревом
Diagram вузлів і FEO діаграмою.
Go to Parent Перехід до батьківської діаграми.
Diagram
Go to Child Перехід до дочірньої діаграми.
Diagram
- DFD External Додавання на діаграму зовнішньої сутності.
Reference
Tool
-DFD Data store Додавання на діаграму сховища даних.
Tool
-IDEF3 Junction Tool Додавання на діаграму перехрестя
-IDEF3 Referent Tool Додавання на діаграму об’єкту посилання
5
Model Explorer - навігатор моделі процесів
Інструмент навігації Model Explorer має три вкладки - Activities, Diagrams
та Objects. Вкладка Activities (діяльність) відображає у вигляді ієрархічного
списку всі діяльності моделі. Іноді діяльність називають просто процесом.
Одночасно можуть бути показані всі моделі, відкриті в програмі. Процеси з
діаграмами в стандарті IDEF0 відображаються зеленим кольором, IDEF3 -
жовтим і DFD - блакитним. Клацання по процесу на вкладці Activity перемикає
ліве вікно AllFusion на діаграму, на якій вона розміщена. Для редагування
властивостей процесу необхідно клацнути по ньому правою кнопкою миші, в
результаті чого з'являється контекстне меню. У табл. 1.2 наведено значення
пунктів меню.
Табл. 1.2. Контекстне меню редагування властивостей процесу
Пункт меню Опис
Insert Before Створити новий процес на тій же діаграмі. У списку
процесів новий процес буде вставлений перед
поточним
Insert After Створити новий процес на тій же діаграмі. У списку
процесів новий процес буде вставлений після
поточного
Decompose Здійснити процес декомпозиції. В результаті буде
створена нова діаграма декомпозиції
Name Виклик редактора назви процесу
Definition/Note Виклик редактора визначення примітки до процесу
Font Зміна шрифту процесу
Color Зміна кольору процесу
Costs Зміна вартості процесу
Data Usage Асоціація процесу з даними
UDP Задання властивостей, які визначаються
користувачем
UOW Задання властивостей для робіт з IDEF3
Вкладка Activities дозволяє перейти на стандартні діаграми діяльності

(контекстну і декомпозиції), інша вкладка - Diagrams - служить для переходу на
будь-яку діаграму моделі. Після переходу на вкладку Objects на ній
відображаються всі об'єкти, що відповідають обраній на вкладці Diagrams
діаграми, в тому числі процеси, сховища даних, зовнішні посилання, об'єкти
посилань тощо.
6
Створення моделі в стандарті IDEF0
На початкових етапах створення інформаційної системи необхідно
зрозуміти, як працює організація, яку необхідно автоматизувати. Для опису
роботи підприємства необхідно побудувати модель. Така модель повинна бути
адекватна предметній області; отже, вона повинна містити в собі знання всіх
учасників бізнес-процесів організації. Найбільш зручною мовою моделювання
бізнес-процесів є IDEF0, запропонованою Дугласом Россом (SoftTech, Inc.), що
спершу носила назву SADT (Structured Analysis and Design Technique). На початку
70-х років збройні сили США застосували засоби SADT для реалізації проектів
в рамках програми 1САМ (Integrated Computer-Aided Manufacturing) Надалі вона
була прийнята в якості федерального стандарту США з назвою IDEF0. Детальні
специфікації на стандарт IDEF можна знайти на сайті http://www.idef.com.
Побудова моделі якої-небудь системи в методології IDEF0 починається з
визначення контексту моделювання, який включає суб’єкт моделювання, мету
моделювання і точку зору на модель.
Під суб’єктом розуміється сама система, при цьому необхідно точно
встановити, що входить в систему, а що лежить за її межами, іншими словами,
необхідно визначити, що надалі розглядатиметься як компоненти системи, а що
як зовнішня дія.
Мета моделювання. Модель не може бути побудована без чітко
сформульованої мети. Мета повинна відповідати на наступні питання:
• Чому цей процес має бути змодельований?
• Що повинна показувати модель?
• Що може отримати розробник?
Точка зору. Не дивлячись на те, що при побудові моделі беруться до уваги
думки різних людей, модель повинна будуватися з єдиної точки зору. Точку зору
можна представити як погляд людини, яка бачить систему в потрібному для
моделювання аспекті. Точка зору повинна відповідати меті моделювання. У течії
моделювання важливо залишатися на вибраній точці зору.
Після визначення контексту моделювання можна приступати до побудови
контекстної діаграми, що часто називається «чорною скринькою». Цей тип
діаграми дозволяє показати, що подається на вхід і що є результатом процесу,
без деталізації його складових. Ця діаграма містить тільки однин процес, який
представляє всю діяльність підприємства в цілому. Часто при виборі точки зору
на моделі необхідно задокументувати додаткові альтернативні точки зору. Для
цієї мети зазвичай використовують діаграми FEO (For Exposition Only), які
будуть описані далі.
Кожна діаграма в нотаціях IDEF0, IDEF3, DFD призначена для опису одного
або декількох бізнес-процесів. Бізнес-процес – це стійка, цілеспрямована
сукупність взаємозв’язаних видів діяльності (послідовність робіт), яка за певною
технологією перетворить входи у виходи, що представляють цінність для
7
споживача. Результатом моделювання бізнес-процесів є модель, яка відноситься
до одного з трьох типів:
• модель AS - IS (як є) – модель поточної організації бізнес-процесів
підприємства;
• модель TO - BE (як буде) – модель ідеальної організації бізнес-процесів;
• модель SHOULD – BE (як повинно бути) – модель, що ідеалізується, не
відображає реальну організацію бізнес-процесів підприємства.
В лабораторних роботах створюватиметься модель AS - IS.
IDEF0-модель передбачає наявність чітко сформульованої мети, єдиного
суб'єкта моделювання і однієї точки зору. Для внесення області, цілі і точки зору
в моделі IDEF0 в AllFusion необхідно вибрати пункт меню Model / Model
Properties, що викликає діалог Model Properties. Далі на вкладці Purpose
потрібно внести мету і точку зору, а на вкладку Definition - визначення моделі і
опис області. На вкладці Status того ж діалогу можна описати статус моделі
(чорновий варіант, робочий, остаточний тощо), Час створення і останнього
редагування (відстежується надалі автоматично по системній даты). На вкладці
Source описуються джерела інформації для побудови моделі (наприклад,
"Опитування експертів предметної області та аналіз документації"). Вкладка
General служить для внесення назви проекту і моделі, імені та ініціалів учасників
і часових рамок моделі - AS-IS (як є) і ТО-ВЕ (як буде).
Результат опису моделі можна отримати в звіті Model Report. Діалог
побудови звіту по моделі викликається командою: Tools / Reports / Model Report.
У діалозі налаштування необхідно обрати потрібні поля, при цьому автоматично
відображається черговість виведення інформації в звіті (рис. 3).
Рис.1.3. Звіт по моделі

Основу методології IDEF0 складає графічна мова опису бізнес-процесів.
Модель в нотації IDEF0 являє собою сукупність ієрархічно впорядкованих і
взаємопов'язаних діаграм. Кожна діаграма є одиницею опису системи і
розташовується на окремому аркуші. Модель може містити чотири типи діаграм:
• контекстну (в кожній моделі може бути тільки одна контекстна діаграма);
8
• декомпозиції;
• дерева вузлів;
• тільки для експозиції (FEO).
Контекстна діаграма є вершиною деревовидної структури діаграм і являє
собою загальний опис системи та її взаємодії із зовнішнім середовищем. Після
опису системи в цілому проводиться розбиття її на великі фрагменти. Цей процес
називається функціональною декомпозицією, а діаграм, які описують кожен
фрагмент і взаємодію між ними називаються діаграмами декомпозиції. Після
декомпозиції контекстної діаграми проводиться декомпозиція кожного великого
фрагмента системи на більш дрібні і т. д. До досягнення потрібного рівня
деталізації. Після кожного сеансу декомпозиції проводиться сеанси експертизи -
експерти предметної області вказують на відповідність реальних бізнес-процесів
створеним діаграмам. Знайдені невідповідності виправляються, і тільки після
проходження експертизи можна приступати до наступного сеансу декомпозиції.
Так досягається відповідність моделі реальним бізнес-процесам на будь-якому
рівні моделі. Синтаксис опису системи в цілому і кожного її фрагмента
однаковий для всієї моделі.
Діаграма дерева вузлів показує ієрархічну залежність процесів, але не
взаємозв'язки між ними. Діаграм дерев вузлів може бути як завгодно багато,
оскільки дерево може бути побудовано на довільну глибину і не обов'язково з
кореня.
Діаграми для експозиції (FEO) будуються для ілюстрації окремих фрагментів
моделі, для ілюстрації альтернативної точки зору або для спеціальних цілей.
Стрілки (Arrows). Взаємодія процесів із зовнішнім світом описується у

вигляді стрілок. Стрілки є деякою інформацією та позначаються іменниками
(наприклад, «Виріб», «Замовлення»).
У IDEF0 розрізняють п’ять типів стрілок.
1) Вхід (Input) – об’єкти, які використовуються і перетворюються
діяльністю (процесом) для отримання результату (виходу).
Допускається, що процес може не мати жодної стрілки входу. Стрілка
входу входить в ліву грань процесу. При моделюванні інформаційних
систем, коли стрілками є не фізичні об'єкти, а дані, не все так очевидно.
Наприклад, при "Прийомі пацієнта" карта пацієнта може бути і на вході
і на виході, при чому якість цих даних змінюється. Іншими словами, в
такому випадку, щоб виправдати своє призначення, стрілки входу і
виходу повинні бути точно визначені для вказання факту опрацювання
даних (наприклад, на виході - "Заповнена карта пацієнта"). Дуже часто
складно визначити, чи є дані входом або управлінням. В цьому випадку
підказкою може служити те, чи переробляються/чи змінюються дані.
Якщо змінюються, то, швидше за все це вхід, якщо ні - управління.
9
2) Управління (Control) – правила, стратегії, процедури і стандарти які
управляють діями процесу. Стрілки управління несуть інформацію, яка
вказує, що повинен виконувати процес. Кожен процес повинен мати хоч
би одну стрілку управління, яка входить у верхню грань. Управління
впливає на процес, але не перетворюється ним. Якщо мета процесу
змінити процедуру або стратегію, то така процедура або стратегія буде
для процесу входом. У разі виникнення невизначеності в статусі стрілки
(управління або контроль) рекомендується відображати стрілку
управління.
3) Вихід (Output) – інформація або матеріал в який перетворюється входи.
Кожен процес повинен мати хоч би одну стрілку виходу, яка виходить з
його правої грані.
4) Механізм (Mechanism) – ресурси, що виконують діяльність, наприклад
персонал підприємства, станки, пристрої. Стрілка механізму входить в
нижню грань процесу. На розсуд аналітика стрілки механізму можуть
бути відсутніми на моделі.
5) Виклик (Call) – спеціальна стрілка, що вказує на іншу модель процесу.
Стрілка виклику виходить з нижньої частини процесу і використовується
для позначення того, що деякий процес виконується за межами
модельованої системи.
Граничні стрілки ICOM (Input, Control, Output, Mechanism). Стрілки на

контекстній діаграмі служать для опису взаємодії системи з навколишнім світом.
Вони можуть починатися біля межі діаграми і закінчуватися у процесі або
навпаки. Такі стрілки називаються граничними. Для внесення граничної стрілки
потрібно:
• клацнути по кнопці з символом стрілки у палітрі інструментів.
• далі перенести курсор до лівої сторони екрану, поки не з’явиться
початкова штрихова смужка;
• клацнути один раз по смужці (звідки виходить стрілка) і ще раз в лівій
частині процесу з боку входу (де закінчується стрілка);
• повернутися в палітру інструментів і вибрати редагування стрілки .
• клацнути правою кнопкою миші на лінії стрілки, в спливаючому меню
вибрати пункт Name Editor і додати ім’я стрілки в закладці Name діалогу
IDEF0 Arrow Properties.
Стрілки управління, входу, механізму і виходу зображуються аналогічно.
Для малювання стрілки виходу, наприклад, слід клацнути по кнопці з символом
стрілки в палітрі інструментів, клацнути в правій частині процесу з боку виходу
(де починається стрілка), перенести курсор до правої сторони екрану, поки не
з’явиться штрихова смужка, і клацнути один раз по ній.
10
Імена внесених стрілок автоматично заносяться в словник.
Словник стрілок (Arrow Dictionary) редагується за допомогою спеціального
редактора Arrow Dictionary Editor (рис. 1.4), в якому визначається стрілка і
вноситься коментар, що відноситься до неї. Для виклику редактора необхідно
вибрати пункт меню Model\Arrow Editor.
Словник стрілок вирішує дуже важливу задачу. А саме, діаграми
створюються аналітиком для того, щоб провести сеанс експертизи, тобто
обговорити діаграму із спеціалістом предметної області. У будь-якій предметній
області формується професійний сленг, причому часто сленгові вирази носять
нечіткий сенс і сприймаються різними фахівцями по-різному. В той же час
аналітик – автор діаграм повинен застосовувати ті вирази, які найбільш зрозумілі
експертам.
Рис. 1.4. Редактор словника стрілок

Внутрішні стрілки. Для зв’язку між процесами використовуються
внутрішні стрілки, тобто стрілки, які не торкаються межі діаграми, починаються
в одному і закінчуються в іншому процесі.
Для малювання внутрішньої стрілки необхідно в режимі малювання стрілок
клацнути по сегменту (наприклад, виході) одного процесу і потім по сегменту
(наприклад, входу) іншого. У IDEF0 розрізняють п’ять типів зв’язків між
процесами:
• зв’язок по входу (output – input), коли стрілка виходу вищестоящого
процесу (далі – просто вихід) прямує на вхід нижчого за розташуванням;
11
Рис. 1.5 Зв’язок по входу.
• зв’язок по управлінню (output – control), коли вихід процесу, що стоїть
вище, прямує на управління нижчого за розташуванням. Зв’язок по входу
показує домінування вищого процесу. Дані або об’єкти виходу
вищестоящого процесу не змінюються в нижчому за розташуванням;
Рис. 1.6 Зв’язок по управлінню.

• зворотний зв’язок по входу (output – input feedback), коли вихід нижчого за
розташуванням процесу прямує на вхід вищого. Такий зв’язок, як правило,
використовується для опису циклів;
Рис. 1.7 Зворотний зв’язок по входу.

• зворотний зв’язок по управлінню (output – control feedback), коли вихід
нижчого за розташуванням процесу прямує на управління вищого.
Зворотний зв’язок по управлінню часто свідчить про ефективність бізнес-
процесу;
Рис. 1.8 Зворотний зв’язок по управлінню.

• зв’язок вихід-механізм (output – mechanism), коли вихід одного процесу
прямує на механізм іншого. Цей взаємозв’язок використовується рідше за
інших і показує, що однин процес готує ресурси, необхідні для проведення
іншого.
12
Рис. 1.9. Зв’язок вихід-механізм.
У IDEF0 стрілка рідко зображує один об’єкт. Зазвичай вона символізує
набір об’єктів. Оскільки стрілки представляють набори об’єктів, вони можуть
мати множину початкових точок (джерел) і кінцевих точок (призначень). Тому
стрілки можуть розгалужуватися і з’єднуватися різними способами. Вся стрілка
або її частина може виходити з одного або декількох блоків і закінчуватися в
одному або декількох блоках.
Розгалуження стрілок, що зображується у вигляді ліній, що розходяться,
означає, що увесь вміст стрілок або його частина може з’явитися в кожному
відгалуженні. Стрілка завжди позначається до розгалуження, щоб дати назву
всьому набору. Крім того, кожна гілка стрілки може бути помічена або не
помічена відповідно до наступних правил:
• непомічені гілки містять всі об’єкти, вказані в мітці стрілки перед
розгалуженням;
• гілки, помічені після точки розгалуження, містять усі об’єкти або їх
частину, вказані в мітці стрілки перед розгалуженням.
Злиття дуг в IDEF0, що зображується як лінії, що сходяться разом, вказує,
що вміст кожної гілки йде на формування мітки для стрілки, що є результатом
злиття початкових стрілок. Після злиття результуюча стрілка завжди
позначається для вказання нового набору об’єктів, що виник після об’єднання.
Крім того, кожна гілка перед злиттям може позначатися або не позначатися
відповідно до наступних правил:
• непомічені гілки містять всі об’єкти, вказані в загальній мітці дуги після
злиття;
• помічені перед злиттям гілки містять всі або деякі об’єкти з перерахованих
в загальній мітці після злиття.
Створення звітів в AllFusion

Існує три способи створення звітів в AllFusion:
• за допомогою вбудованих шаблонів;
• за допомогою Report Template Builder.
• за допомогою зовнішніх програмних засобів для генерації звітів .зокрема
Crystal Reports.
Звіти на основі вбудованих шаблонів можна створити, вибравши з меню Tools
/ Reports необхідний тип шаблону. Всього є сім типів шаблонів звітів:
13
1. Model Report – включає інформацію про контекст моделі - ім'я моделі,
точку зору, область, мету, ім'я автора, дату створення та ін.
2. Diagram Report – звіт по конкретній діаграмі. Включає список об'єктів
(процесів, стрілок, сховищ даних, зовнішніх посилань тощо).
3. Diagram Object Report – найбільш повний звіт по моделі. Може включати
повний список об'єктів моделі (процесів, стрілок із зазначенням їх типу та
ін.) і властивості, що визначаються користувачем.
4. Activity Cost Report – звіт про результати вартісного аналізу. Буде
розглянуто далі.
5. Arrow Report – звіт по стрілках. Може містити інформацію зі словника
стрілок, інформацію про процес-джерело і інформацію про розгалуження і
злиття стрілок.
6. DataUsage Report – звіт про результати зв'язування моделі процесів і
моделі даних..
7. Model Consistency Report – звіт, що містить список синтаксичних помилок
моделі.
Синтаксичні помилки IDEF0 з точки зору AllFusion поділяються на три типи:
По-перше, це помилки, які AllFusion виявити не в змозі. Наприклад,
синтаксис IDEF0 вимагає, щоб назва процесу була представлена віддієслівним
іменником, що виражає процес. AllFusion не дозволяє аналізувати синтаксис
мови і сенс імен об'єктів і тому ігнорує помилки цього типу. Виявлення таких
помилок - ручна робота.
По-друге, це потенційні помилки, які AllFusion просто не допускає.
Наприклад, кожна грань процесу призначена для певного типу стрілок. AllFusion
просто не дозволить створити на діаграмі IDEF0 внутрішню стрілку, що
виходить з лівої межі процесу і входить в праву.
По-третє, це такі помилки, які AllFusion дозволяє допустити, проте
здійснює їх детекування. Повний список останніх можна отримати в звіті Model
Report. Список помилок може містити, наприклад, неіменовані процеси і стрілки
(unnamed arrow, unnamed activity), незв'язані стрілки (unconnected border arrow),
недозволені стрілки (unresolved (square tunneled) arrow connections) і т. д.
При виборі пункту меню, який відповідає якомусь звіту, з'являється
діалогове вікно налаштування звіту. Для кожного з семи типів звітів він виглядає
по-своєму. Розглянемо типовий діалог Arrow Report (рис. 1.11).
14
Рис.1.10 Приклад звіту
Список, що розкривається Standart Reports дозволяє вибрати один із
стандартних звітів. Стандартний звіт - це запам'ятовувана комбінація
перемикачів, прапорців та інших елементів управління. Для створення власного
стандартного звіту необхідно задати опції звіту, ввести ім'я звіту в поле списку
вибору і клацнути по кнопці New. AllFusion зберігає інформацію про
стандартний звіт в файлі BPWINRPT.INI. Значення цього файлу доступні з будь-
якої моделі. Єдине обмеження - властивості, що визначаються користувачем
(User-Defined Properties) які зберігаються у вигляді покажчика і тому доступні
тільки з "рідної" моделі. Стандартний звіт можна змінити (кнопка Update) або
видалити (кнопка Delete).
У правому верхньому куті діалогу знаходиться група керуючих елементів
для вибору формату звіту. Наявні такі формати:
• Labeled - звіти включають мітку поля, а в наступному рядку, друкується
вміст поля;
• Fixed Column - кожне поле друкується у власній колонці;
• Tab-Comma Delimited - кожне поле друкується у власній колонці. Колонки
виділяються знаком табуляції або комами;
• DDE Table - дані передаються по протоколу DDE в додаток, наприклад в
MS Word або Excel.
Опція Ordering (в звіті по стрілках відсутня) сортує дані за визначеним
значенням.
Опція Multi-Valued Format регулює виведення полів в звіті при групуванні
даних:
15
• Repeating Group - детальні дані які об'єднуються в одне поле, між
значеннями вставляється плюс (+) ;.
• Filled - дублювання даних для кожного заголовка групи;
• Header (опція за замовчуванням) - друкується заголовок групи, потім -
детальна інформація.
Рис.1.11. Діалог Arrow Report
Створення звітів за допомогою Report Template Builder

Report Template Builder є простим генератором звітів, який входить до
складу AllFusion. Викликається цей інструмент за допомогою команди меню
Tools / Reports Builder. Основною перевагою є можливість публікації результатів
моделювання на Web-сайті.
Пункт меню Tools / Reports Builder викликає діалог Report Templates, який
служить для створення шаблону звіту. Кнопка New застосовується для створення
нового шаблону, кнопка Edit - редагування існуючого. Список вибору Output
Type задає формат результату виконання звіту. Звіт може бути експортований в
текстовий формат, RTF і HTML. Кнопка Run дозволяє виконати звіт.
Діалог Report Template Builder (рис. 1.12) містить два списки і панель
інструментів. У лівій частині діалогу міститься список можливих секцій звіту,
відповідних типів об'єктів моделі, в правій - список секцій, включених до звіту.
Особливий інтерес представляє розділ Graphical. З його допомогою можна
включати в звіт графічні об'єкти (секція Picture) - діаграми моделей даних або
моделей процесів.
16
Рис. 1.12. Діалог Report Template Builder
По замовчуванню, в звіт включається тільки ім'я об'єкта. Для включення
інших властивостей необхідно за допомогою меню Edit / Properties або
відповідної кнопки на панелі інструментів викликати діалог Properties. Для
генерації звіту слід натиснути на кнопку (Виконати звіт). Якщо в звіт включена
секція Picture і встановлена опція Specify at Run Time, то виникає діалог Diagram
Selection and Scaling , в якому можна вибрати діаграми для включення їх до звіту.
Методика виконання роботи

В якості прикладу роботи розглянемо діяльність деякої компанії «Computer
Word». Компанія займається в основному складанням і продажом комп'ютерів і
ноутбуків. Компанія не виробляє компоненти ,а лише здійснює збирання і
тестування. Основні види робіт в компанії:
• продавці приймають замовлення клієнтів;
• оператори групують замовлення за типами комп'ютерів;
• оператори збирають і тестують комп'ютери;
• оператори упаковують комп'ютери відповідно до замовлень;
• комірник відвантажує клієнтам замовлення.
Компанія використовує ліцензійну бухгалтерську інформаційну систему,
яка дозволяє оформити замовлення, рахунок і відстежити платежі за рахунками.
На початку необхідно створити нову діаграму в (IDEF0). Далі
відкриється діалогове вікно Properties for New Models (властивості нової моделі)
в якому необхідно ввести Author (Автор) прізвище автора моделі та заповнити
17
інші вкладки. На вкладці General в текстове поле Model name необхідно ввести
назву моделі "Аналізувати діяльність компанії", а в текстове поле Project назву
проекту "Модель діяльності компанії", а в текстове поле Time Frame – AS–IS (Як
є). На вкладці Purpose діалогового вікна Model Properties в текстове поле Purpose
внести дані що стосуються мети розробки моделі – "Моделювати поточні (AS–
IS) бізнес–процеси компанії", а в текстове поле Viewpoint (точка зору) –
"Директор". На вкладці Definition діалогового вікна Model Properties в текстове
поле Definition необхідно внести "Це навчальна модель, яка описує діяльність
компанії», а в текстове поле Scope – "Загальне управління бізнесом компанії:
дослідження ринку, закупівля компонентів, складання, тестування і продаж". В
результаті зазначених дій створюється незаповнена контекстна діаграма.
Рис.1.13 Незаповнений блок

Далі необхідно створити ICOM – стрілки на контекстній діаграмі згідно з
табл. 1.3.
Табл.1.3. Стрілки контексної діаграми
Назва стрілки Визначення стрілки Тип стрілки
(Arrow Name) (Arrow Definition) (Arrow Type)
Дзвінки клієнтів Запити інформації, замовлення, Input
техпідтримка тощо
Правила і процедури Правила продажу, інструкції по складанню, Control
процедури тестування, критерії
продуктивності
Продані товари Настільні і портативні комп'ютери Output
Бухгалтерська Оформлення рахунків, оплата рахунків, Mechanism
система робота із замовленнями.
18
Внесення відповідних стрілок на діаграму здійснюється згідно з
послідовністю описаною в теоретичних відомостях. Для додавання назви стрілки
необхідно клацнути правою кнопкою миші на лінії стрілки і в спливаючому
меню обрати Name в якому і надрукувати назву стрілки "Дзвінки клієнтів". Далі
здійснити подвійне клацання лівою кнопкою миші на лінії стрілки. В результаті
відкриється розширений діалог Arrow Properties на вкладці Definition якого
необхідно написати призначення стрілки входу Input відповідно до табл. 1.3.
Стрілки управління, виходу і механізму зображуються аналогічно.
Рис.1.14. Побудована контексна діаграма

Далі необхідно створити звіт по моделі. У меню Tools / Reports / Model
Report задати всі опції генерування звіту і натиснути кнопку Preview (попередній
перегляд). В результаті буде сформований звіт, як показано на рис. 1.15.
Рис.1.15. Попередній перегляд звіту
19
Порядок виконання роботи.
1. Ознайомитись з теоретичними відомостями.
2. Відповідно до індивідуального завдання (номер варіанту індивідуального
завдання відповідає порядковому номеру студента в списку групи),
коротко описати предметну область (чим займається підприємство, які
основні процеси в ньому відбуваються).
3. Визначити контекст моделювання. Використовуючи наведений приклад,
побудувати контекстну діаграму в нотації IDEF0 відповідно до
індивідуального завдання. Спроектована модель має деталізовано
відображати множину інформаційних потоків, що показують аспекти
функціонування. Модель AS – IS. Точка зору – з позиції людини, яка
найкраще знає структуру предметної області.
4. Здійснити генерацію звіту по моделі та зберегти результати роботи.
5. Всі результати роботи повинні бути приведені в звіті та детально описані
Контрольні запитання.
1. Поняття методології IDEF0.
2. Призначення стрілок в методології IDEF0.
3. Типи стрілок в методології IDEF0. Граничні стрілки. Словник стрілок.
4. Особливості тестування моделей в AllFusion Process Modeler.
Пропоновані теми:
1. Інформаційна система проведення безготівкових розрахунків
2. Інформаційна система обліку кадрів на підприємстві.
3. Інформаційна система управління процесами збуту.
4. Інформаційна система формування бухгалтерської звітності.
5. Інформаційна система виробництва металу та металовиробів.
6. Інформаційна система переробки м’яса.
7. Інформаційна система виготовлення меблів.
8. Інформаційна система в готельному бізнесі
9. Інформаційна система екологічного моніторингу.
10.Інформаційна система замовлення квитків
11.Інформаційна система виробництва освітлювальних приладів.
12.Інформаційна система «Навчальний заклад»
13.Інформаційна система обліку пацієнтів в медичних закладах.
14.Інформаційна система в туристичному бізнесі
15.Інформаційна система обліку матеріальних цінностей.
16.Інформаційна система діяльності ріелтерської компанії
17.Інформаційна система нарахування заробітної плати
18.Інформаційна система виробництва автомобілів
19.Інформаційна система виробництва хлібобулочних виробів.
20.Інформаційна система нарахування митних платежів.
21.Інформаційна система виробництва радіоелектронних пристроїв.
20
22.Інформаційна система обліку готової продукції.
23.Інформаційна система бібліотечної діяльності
24.Інформаційна система діяльності фотолабораторії
25.Інформаційна система проектування пристроїв захисту інформації
26.Інформаційна система обліку технічного стану автомобілів
27.Інформаційна система планування та контролю тренувань
28.Інформаційна система процесу замовлення товарів
29.Інформаційна система цифрової дистрибуції
30.Інформаційна система розпізнавання стилю плавання
21
Створення діаграми декомпозиції

інтегрованих систем та навчитись будувати діаграми декомпозиції.
Діяльність (процес) позначає поіменовані функції або завдання, які
проходять протягом певного часу і мають розпізнавані результати та
зображуються у вигляді прямокутників. Всі процеси повинні бути названі і
визначені. Ім'я діяльності повинне бути виражено поєднанням дієслівного
іменника, що позначає процес, наприклад: "Виготовити деталь ", "Прийняти
замовлення" і т.д. Діаграми декомпозиції призначені для деталізації діяльності.
Для створення діаграми декомпозиції необхідно клацнути по кнопці .
Виникає діалог Activity Box Count (рис. 2.1), в якому слід вказати нотацію нової
діаграми і кількість діяльностей на ній. Зупинимося поки на нотації IDEF0 і
клацнемо на ОК. З'являється діаграма декомпозиції. Допустимий інтервал
кількості діяльностей 2-8. Здійснювати декомпозицію однієї діяльності немає
сенсу, а процес декомпозиції з кількістю діяльностей більше восьми є
перенасичений елементами. Для забезпечення наочності і кращого розуміння
модельованих процесів рекомендується використовувати від 3 до 6 блоків на
одній діаграмі.
Рис.2.1. Діалог Activity Box Count

Якщо виявиться, що кількість процесів є недостатньою, то процес можна
додати на діаграму, клацнувши спочатку по кнопці на палітрі інструментів,
а потім по вільному місцю на діаграмі.
Процеси на діаграмах декомпозиції зазвичай розташовуються по діагоналі
від лівого верхнього кута до правого нижнього. Такий порядок називається
порядком домінування. Згідно з цим принципом розташований в лівому
верхньому куті процес є найважливішим або таким, що виконується першим.
Далі вправо-вниз розташовуються менш важливі процеси, або ті які виконуються
пізніше. Таке розташування значно полегшує читання діаграм, крім того, на
ньому ґрунтується поняття взаємозв'язків між процесами.
22
Кожен процес на діаграмі декомпозиції може бути, в свою чергу підданий
декомпозиції. На діаграмі декомпозиції процеси нумеруються автоматично зліва
направо. Номер процесу відображається в правому нижньому кутку. У лівому
верхньому кутку відображається невеликий діагональний відрізок, який показує,
що даний процес не була підданий декомпозиції.
ICOM-коди.
ICOM (абревіатура від Input, Control, Output і Mechanism) - коди,
призначені для ідентифікації граничних стрілок. Код ICOM містить префікс,
який відповідає типу стрілки (I, С, О або М), і порядковий номер. AllFusion
вносить ICOM-коди автоматично. Для відображення ICOM-кодів необхідно
включити опцію ICOM codes на вкладці Display діалогу Model Properties (меню
Model/Model Properties). Назви внесених стрілок автоматично заносяться в
словник (Arrow Dictionary). Словник стрілок редагується за допомогою
спеціального редактора Arrow Dictionary, в якому визначається стрілка і
вноситься відноситься до неї коментар.
Незв'язані граничні стрілки (Unconnected Border Arrow). При декомпозиції
процесу вхідні та вихідні стрілки (крім стрілок виклику) автоматично
з'являються на діаграмі декомпозиції (міграція стрілок), проте це не стосується
власне процесу. Такі стрілки називаються незв'язаними і сприймаються в
AllFusion як синтаксична помилка.
Для зв'язування стрілок входу, управління або механізму необхідно
перейти в режим редагування стрілок, клацнувши по закінченню (наконечнику)
стрілки та відповідному сегменті процесу. Для зв'язування стрілки виходу
необхідно перейти в режим редагування стрілок, клацнути по сегменту виходу
процесу а потім по стрілці.
Тунелювання стрілок. Знову внесені граничні стрілки на діаграмі
декомпозиції нижнього рівня є недозволеними та зображуються в квадратних
дужках. Тому вони автоматично не з’являються на діаграмі верхнього рівня. Для
їх "перетягування" наверх потрібно натиснути правою кнопкою миші на
квадратній дужці граничної стрілки в результаті чого з'являється діалог Border
Arrow Editor. Якщо вибрати опцію Resolve it to border arrow, стрілка мігрує на
діаграму верхнього рівня, а якщо вибрати Change it to resolved rounded tunnel -
стрілка буде затунелена і не потрапить на іншу діаграму. Тунельна стрілка
зображується з круглими дужками на кінці.
Тунелювання може бути застосовано для відображення малозначущих
стрілок. Якщо на будь-якій діаграмі нижнього рівня необхідно зобразити
малозначущі дані або об'єкти, які не обробляються або не використовуються
процесами на поточному рівні, то їх необхідно направити на вище стоячий рівень
(на батьківську діаграму). Якщо ці дані не використовуються на батьківській
діаграмі, їх потрібно направити ще вище і т. д. В результаті малозначима стрілка
23
буде зображена на всіх рівнях і утруднить читання всіх діаграм, на яких вона
присутня. Виходом є тунелювання стрілки на найнижчому рівні. Таке
тунелювання називається "не в батьківській діаграмі".
Іншим прикладом тунелювання є ситуація, коли стрілка механізму мігрує
з верхнього рівня на нижній, причому на нижньому рівні цей механізм
використовується однаково у всіх процесах без винятку. (Припускається, що не
потрібно деталізувати стрілку механізму, тобто стрілка механізму на дочірньому
процесі іменується до розгалуження, а після розгалуження гілки не має власного
імені.) У цьому випадку стрілка механізму на нижньому рівні може бути
видалена, після чого на батьківській діаграмі вона може бути затунелена, а в
коментарі до стрілки або в словнику можна вказати, що механізм буде
використовуватися у всіх процесах дочірньої діаграми декомпозиції. Таке
тунелювання називається "не в дочірньому процесі".
Методика виконання роботи

На початку роботи необхідно завантажитти файл з попередньою роботою
та клацнути по кнопці на панелі інструментів. У створеному діалоговому
вікні Activity Box Count встановити кількість процесів на діаграмі нижнього
рівня - 3 і натиснути кнопку ОК. В результаті зазаначених дій буде створена
діаграма декомпозиції (рис. 2.2).
Рис. 2.2. Діаграма декомпозиції
24
Далі необхідно ввести назви створених процесів шляхом виклику пункту
Name у контекстному меню. Потім внести визначення, статус і джерело для
кожного процесу згідно з даними табл. 2.1.
Табл.2.1. Процеси діаграми декомпозиції А0
Назва процесу Визначення процесу
(Activity Name) (Activity Definition)
Провести маркетингову Телемаркетинг і презентації, виставки
політику
Здійснити збирання Збирання і тестування настільних і портативних
комп’ютерів комп'ютерів
Провести відвантаження Відвантаження замовлень клієнтам і отримання
та проконтролювати компонентів від постачальників
отримання
Далі необхідно перейти в режим рисування (редагування) стрілок,
скориставшись кнопкою на палітрі інструментів. Необхідно пов’язати
граничні стрілки з процесами так, як це показано на рис. 2.3. Для зв'язування
стрілок входу, управління або механізму потрібно клацнути на наконечнику
стрілки, а потім по відповідному сегменту процесу. Для зв'язування стрілки
виходу необхідно клацнути по сегменту виходу процесу і потім по стрілці.
Для розгалуження стрілки потрібно клацнути по фрагменту стрілки (в
точці розгалуження) і по відповідному сегменту процесу. Для злиття двох
стрілок виходу потрібно спочатку клацнути по сегменту виходу процесу, а потім
по відповідному фрагменту стрілки. Необхідно зробити розгалуження стрілки
управління "Правила і процедури" на три стрілки до всіх трьох процесів та
розгалуження стрілки механізму "Бухгалтерська система" на дві стрілки до
процесів 1 і 3.
Далі необхідно клацнути правою кнопкою миші по гілці стрілки керування
процесу "Здійснити збирання комп'ютерів" і перейменувати її в "Правила
збирання і тестування". Далі необхідно внести визначення для нової гілки:
"Інструкції по збиранню, процедури тестування, критерії продуктивності".
Клацнути правою кнопкою миші по гілці стрілки механізму процесу "Провести
маркетингову політику" і перейменувати її в "Система оформлення замовлень".
25
Рис.2.3. Пов'язані граничні стрілки на діаграмі А0
Далі необхідно створити нові внутрішні стрілки так, як показано на рис.

2.4. Для рисування внутрішньої стрілки необхідно в режимі рисування стрілок
клацнути по сегменту (наприклад, виходу) одного процесу і потім по сегменту
(наприклад, входу) іншого. Щоб змінити, наприклад, товщину або колір стрілки
або текст, потрібно спочатку вийти з режиму рисування стрілки, шляхом
натиснення кнопки на палітрі інструментів. Потім здійснити одне клацання по
стрілці правою кнопкою миші або подвійне клацання лівою кнопкою миші. І в
утвореному вікні вибрати відповідний пункт з меню або вкладку. Для зміни
кольору стрілки потрібно вибрати Color, для зміни товщини – Style, для зміни
шрифту – Font.
Необхідно створити стрілку зворотного зв'язку (по управлінню)
"Результати складання і тестування", що направлена від процесу "Здійснити
збирання комп’ютерів" до процесу "Провести маркетингову політику". Методом
drag & drop перенести назви стрілок так, щоб їх було зручніше читати. Якщо
необхідно, встановити з контекстного меню елемент Squiggle. Результат
можливих змін показаний на рис. 2.4.
26
Рис. 2.4. Результат редагування стрілок на діаграмі А0
Створити нову граничну стрілку виходу "Маркетингові матеріали", що
виходить з процесу "Провести маркетингову політику". Ця стрілка автоматично
не потрапляє на діаграму верхнього рівня і має квадратні дужки на закінченні
(Рис. 2.5).
Рис.2.5. Стрілка Маркетингові матеріали
27
Клацнути правою кнопкою миші по квадратних дужках і вибрати пункт
меню Arrow Tunnel. У діалоговому вікні Border Arrow Editor (Редактор
Граничних Стрілок) вибрати опцію Resolve it to Border Arrow (Дозволити як
Граничну Стрілку). Переконайтеся, що на діаграмі А-0 з'явилася нова стрілка
"Маркетингові матеріали", яка мігрувала з діаграми А0. Для стрілки
"Маркетингові матеріали" вибрати опцію Trim з контекстного меню. Результат
виконання показаний на рис. 2.6.
Рис.2.6. Результат виконання роботи

Здійснимо побудову діаграми декомпозиції А2 на прикладі декомпозиції
процесу "Здійснити збирання комп‘ютерів". В результаті проведення аналізу
було отримано таку інформацію. Виробничий відділ отримує замовлення
клієнтів від відділу продаж по мірі їх надходження.
Диспетчер координує роботу складальників, сортує замовлення, групує їх
і дає розпорядження на відвантаження комп'ютерів у випадку їх готовності.
Кожні 2 години диспетчер групує замовлення – окремо для настільних
комп’ютерів та ноутбуків - і направляє на ділянку складання. Співробітники
ділянки складання збирають комп'ютери відповідно до специфікації замовлення
та інструкцій по збиранню. Коли група комп'ютерів, що відповідає відповідній
групі замовлень, зібрана, вона направляється на тестування. Тестувальники
тестують кожен комп'ютер і в разі необхідності замінюють несправні
компоненти. Далі вони направляють результати тестування диспетчеру, який на
28
підставі цієї інформації приймає рішення про передачу комп'ютерів, що
відповідає групі замовлень, на відвантаження.
На основі цієї інформації необхідно створити нові процеси і стрілки (табл.
2.2., 2.3).
Табл.2.2. Процеси діаграми декомпозиції А2
Назва процесу Визначення процесу
(Activity Name) (Activity Definition)
Відстежити розклад та Перегляд замовлень, встановлення розкладу виконання
керувати збиранням і замовлень, перегляд результатів тестування, формування груп
тестуванням замовлень на складання і відвантаження
Здійснити складання Складання настільних комп'ютерів відповідно до інструкцій і
настільних комп'ютерів вказівок диспетчера
Здійснити складання Складання ноутбуків відповідно до інструкцій і вказівок
ноутбуків диспетчера
Провести тестування Тестування комп'ютерів і компонентів. Заміна непрацюючих
комп'ютерів компонентів
Табл.2.3. Стрілки діаграми декомпозиції А2

Найменування Джерело стрілки Тип стрілки «Отримувач стрілки» Тип
стрілки (Arrow Source) джерела (Arrow Dest.) стрілки
(Arrow Name) отримувач
а
Диспетчер Персонал виробничого Відстежити розклад та Mechanis
відділу керувати збиранням і m
тестуванням
Замовлення Границя діаграми Control Відстежити розклад та Control
клієнтів керувати збиранням і
Замовлення на Відстежити розклад та Output Здійснити складання Control
настільні керувати збиранням і настільних комп'ютерів
комп’ютери тестуванням
Замовлення на Відстежити розклад та Output Здійснити складання Control
ноутбуки керувати збиранням і ноутбуків
Компоненти "Tunnel" Input Здійснити складання Input
настільних комп'ютерів
Здійснити складання Input
ноутбуків
Провести тестування Input
комп'ютерів
Настільні Здійснити складання Output Провести тестування Input
комп'ютери настільних комп'ютерів
Ноутбуки Здійснити складання Output Провести тестування Input
ноутбуків комп'ютерів
"Tunnel" Здійснити складання Mechanis
настільних комп'ютерів m
29
Персонал Здійснити складання Mechanis
виробничого ноутбуків m
відділу
Правила Границя діаграми Здійснити складання Control
збирання і настільних комп'ютерів
тестування Здійснити складання Control
ноутбуків
Провести тестування Control
Результати Здійснити складання Output Границя діаграми Output
складання і настільних
тестування комп'ютерів
Здійснити складання Output
ноутбуків
Провести тестування Output
Результати Провести тестування Output Відстежити розклад та Input
тестування комп'ютерів керувати збиранням і
Зібрані Провести тестування Output Границя діаграми Output
комп'ютери комп'ютерів
Тестувальник Персонал виробничого Провести тестування Mechanis
відділу комп'ютерів m
Вказівка щодо Відстежити розклад та Output Провести тестування Control
передачі керувати збиранням і комп'ютерів
комп'ютерів на тестуванням
відвантаження
Здійснити процес тунелювання та зв’язування на верхньому рівні
граничних стрілок у випадку необхідності (рис. 2.7).
Рис. 2.7. Декомпозиція процесу Здійснити збирання комп‘ютерів
30
2. Використовуючи наведений приклад, побудувати діаграму декомпозиції
А0 та А2 в нотації IDEF0 відповідно до індивідуального завдання.
3. Використати всі можливі елементи нотації описані в методичних вказівках
4. Здійснити генерацію звіту по моделі та зберегти результати роботи.
5. Навести короткий опис кожного процесу.
1. Поняття діаграми декомпозиції.
2. Вимоги до процесу декомпозиції
3. Поняття та призначення ICOM-кодів
4. Тунелювання стрілок в IDEF0
31
Створення діаграми потоків даних (Data Flow Diagram)

інтегрованих систем та навчитись будувати діаграму потоків даних в нотації
Гейна-Сарсона.
Діаграми потоків даних (Data flow diagram, DFD) використовуються для
опису документообігу і обробки інформації. Подібно до IDEF0, DFD представляє
модельовану систему як мережу пов’язаних між собою процесів. Головна мета
DFD – показати, як кожен процес перетворює свої вхідні дані у вихідні, а також
виявити відношення між ними. Таким чином, основними компонентами діаграм
потоків даних є: зовнішні сутності; системи/підсистеми; процеси; накопичувачі
даних; потоки даних. Нотація Гейна-Сарсона ґрунтується на ідеї висхідної
ієрархічної організації метою якої є перетворення загальних, нечітких знань про
вимоги до системи в точні (наскільки це можливо) визначення. Вона фокусує
увагу на потоках даних, її головне призначення – створення в графіці документів
за функціональними вимогами. Дане представлення підтримується традиційними
висхідними засобами проектування специфікацій і забезпечує один з кращих
засобів зв'язку між аналітиками, розробниками і користувачами системи.
Відповідно до останньої модель системи визначається як ієрархія діаграм
потоків даних, що описують асинхронний процес перетворення інформації від її
введення в систему до видачі користувачу. Діаграми верхніх рівнів ієрархії
визначають основні процеси або підсистеми із зовнішніми входами і
виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така
декомпозиція продовжується, створюючи багаторівневу ієрархію діаграм доти,
поки не буде досягнуто такий рівень декомпозиції, при якому процеси стають
елементарними і деталізувати їх далі неможливо.
Зовнішня сутність представляє собою матеріальний предмет або фізичну
особу, що представляє собою джерело або приймач інформації, наприклад,
замовники, персонал, постачальники, клієнти, склад. Визначення деякого
об'єкта або системи в якості зовнішньої сутності вказує на те, що вона перебуває
за межами аналізованої системи. У процесі аналізу деякі зовнішні сутності
можуть бути перенесені всередину діаграми, якщо це необхідно, або, навпаки,
частина процесів системи може бути винесена за межі діаграми і подана як
зовнішня сутність. Зовнішні сутності представляються у вигляді прямокутника з
тінню і зазвичай розташовуються по краях діаграми (рис.3.1):
32
Рис.3.1. Зовнішня сутність
Процес (діяльність) являє собою перетворення вхідних потоків даних на
вихідні відповідно до визначеного алгоритму. У реальному житті процес може
виконуватися деяким підрозділом організації, що опрацьовує вхідні документи і
готує звіти, окремим співробітником, програмою чи спеціальним логічним
пристроєм. Процеси зображуються прямокутниками із закругленими кутами
(рис. 3.2). Вони мають входи і виходи, але не підтримують управління і
механізми, як в IDEF0. Усі сторони прямокутника рівнозначні. У кожен процес
може входити і виходити по декілька стрілок.
Рис. 3.2. Процес в DFD

Стрілки (потоки даних). Стрілки описують рух об’єктів з однієї частини
системи в іншу (діаграма DFD не може мати граничних стрілок). Оскільки усі
сторони процесу в DFD рівнозначні, то стрілки можуть починатися і
закінчуватися на будь-якій стороні прямокутника. Стрілки також можуть бути
двонаправленими.
Накопичувачі даних (Сховище даних). На відміну від стрілок, що описують
об’єкти в русі, сховища даних зображують об’єкти у статичному режимі (рис.
3.3). Сховище даних – це абстрактний пристрій для зберігання інформації, яку
можна у будь-який момент помістити в накопичувач і через деякий час
витягнути, причому способи приміщення і витягання можуть бути будь-якими.
В загальному випадку сховище даних є прообразом майбутньої бази даних. Опис
даних, що зберігаються в ньому, повинен відповідати інформаційній моделі
(Entity - Relationship Diagram).
Рис. 3.3. Сховище даних в DFD
33
Злиття і розгалуження стрілок. У DFD стрілки можуть зливатися і
розгалужуватися, що дозволяє описати декомпозицію стрілок. Кожен новий
сегмент стрілки, що зливається або розгалужується, може мати власне ім’я.
Нумерація об’єктів. У DFD номер кожного процесу може включати
префікс, номер батьківського процесу (А) і номер об’єкту. Номер об’єкту – це
унікальний номер процесу на діаграмі. Унікальний номер мають сховища даних
і зовнішні сутності незалежно від їх розташування на діаграмі. Кожне сховище
даних має префікс D і унікальний номер, наприклад D5. Кожна зовнішня сутність
має префікс E і унікальний номер.
Для побудови концептуальної моделі буде використовуватися бізнес-
процес, пов'язаний із призначенням лікування та створення нагадувань, щодо
приймання ліків, тому назва моделі буде: інформаційна система призначення
лікування та створення нагадувань. Для того, щоб побудувати діаграму DFD,
потрібно створити новий документ і у вкладці, що відкрилася, обрати Data Flow
(DFD), а у полі Name ввести назву моделі.
Рис.3.4. Вибір типу моделі

DFD розглядає систему як сукупність предметів. Тому контекстна діаграма
включає процеси і зовнішні сутності. Процеси, являють собою дієслова, які
визначають функціональність системи. Включення зовнішніх сутностей в
контекстну діаграму не відміняє вимоги методології чітко визначити мету,
область і єдину точку зору на модельовану систему.
Для завдання імені основного процесу необхідно двічі клацнути по
прямокутнику (поки ще "порожньому"), потім у вікні "Activity Properties",
записати назву. У результаті одержимо наступний вигляд діаграми (рис. 3.5).
34
Рис. 3.5. Назва зовнішньої сутності
Послідовність подальших дій для побудови моделі показана на рис. 3.6 - 3.9.
Рис. 3.6. Створення зовнішньої сутності у вікні External Reference
Рис.3.7. Розміщення зовнішніх сутностей на контекстній діаграмі
35
Для побудови інтерфейсних дуг (стрілок) необхідно: вибрати кнопку із
символом стрілки (Precedence Arrow Tool) палітрі інструментів у і перенести
курсор на відповідну зовнішню сутність, від якої необхідно провести
інтерфейсну дугу. Клацнути один раз по ній, і ще раз по відповідному процесі з
яким необхідно її сполучити. Для налаштування параметрів потрібно клацнути
правою кнопкою миші на лінії стрілки і в контекстному меню вибрати пункт
Name, де і додати ім’я стрілки. Аналогічно будуються інші стрілки (рис.3.8).
Рис.3.8. Налаштування параметрів інтерфейсної дуги

Після завершення описаних дій, отримаємо контекстну діаграму, що
представлена на рис.3.9.
Рис.3.9. Контекстна діаграма проектованої системи
36
Збереження проектної версії DF-діаграми в текстовому документі
здійснюється з використанням команди Edit/Copy Picture (рис. 3.10).
USED AT: AUTHOR: Басюк Т.М. DATE: 01.04.2022 WORKING READER DATE CONTEXT:
PROJECT: інформаційна система призначення лікування REV: 01.04.2022 DRAFT
та створення нагадувань
RECOMMENDED
TOP
NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION
Інформація про особу
1
Параметри нагадування
Пацієнт
Отримані дані
0UAH 0
Інформація про лукування
Призначити лікування та створити нагадування

Сповіщення про прийом ліків
2
Лікар
Запит на уточнення діагнозу
NODE: TITLE:
Призначити лікування та створити нагадування NUMBER:
A-0
Рис. 3.10. Збереження проектної версії DF-діаграми

Для деталізації (декомпозиції) діаграми потоків даних, необхідно клацнути
на кнопці декомпозиції (Go to Child Diagram) на панелі інструментів (рис. 3.11)
і вказати кількість процесів (у нашому випадку 4), натиснути ОК.
Рис. 3.11. Вибір кількості процесів для декомпозиції

В результаті одержуємо перший рівень декомпозиції, наведений на
рис. 3.12.
37
Рис. 3.12. Перший етап декомпозиції DF-діаграми
Функціонально задача розбивається на наступні процеси: здійснити вхід в
обліковий запис; встановити діагноз; надати рекомендації; налаштувати
нагадування, відображення яких здійснюється аналогічно, як в попередніх
діаграмах. Результат декомпозиції першого рівня наведено на рис.3.13.
Рис. 3.13. Деталізована (декомпозиція 1 рівня) діаграма потоків даних
38
Процес «Здійснити вхід в обліковий запис» відповідає за реєстрацію та
авторизацію користувача. Після успішної автентифікації пацієнт отримує доступ
до свого облікового запису та має можливість вибрати ознаки захворювання для
подальшого визначення медичного діагнозу.
Процес «Встановити діагноз» являє собою визначення найбільш ймовірного
захворювання пацієнта відповідно до вибраних ним систем органів та симптомів,
які витягуються з накопичувача даних під назвою «Категорії симптомів систем
органів». Процес «Надати рекомендації» відповідає за визначення лікування
встановленого захворювання, а також надсилання консультаційної інформації
користувачу. За допомогою накопичувача даних «Препарати» користувач може
отримати список ліків та інформацію про особливості їх застосування при
конкретному захворюванні. В процесі «Налаштувати нагадування» відповідно
до введених параметрів нагадування генерується сповіщення про прийом ліків,
яке записується в історії нагадувань, щоб користувач зміг в будь-який момент
переглянути курс лікування.
Для ще більш точнішого представлення інформації необхідно деталізувати
процеси діаграми потоків даних першого рівня. Процес «Здійснити вхід в
обліковий запис» (рис. 3.14) деталізується на підпроцеси «Здійснити реєстрацію
користувача» та «Здійснити авторизацію користувача», які показують, що
неможливо увійти в систему без попередньої реєстрації або з некоректними
обліковими даними.
Рис. 3.14. Деталізована (декомпозиція 2 рівня) діаграма потоків даних для

процесу «Здійснити вхід в обліковий запис»
Процес «Встановити діагноз» (рис. 3.15) деталізується на три підпроцеси, а
саме: «Здійснити пошук симптомів по системі органів», відбирає всі симптоми
до вибраних систем органів та надсилає запит на вилучення переліку хворіб
відповідно до вибраних користувачем симптомів до накопичувача даних «Мапа
захворювань і симптомів. Підпроцес «Обчислити ймовірність захворювання за
вибраними симптомами» визначає з списку можливих хворіб найбільш вірогідні
за допомогою алгоритму дерева рішень. В підпроцесі «Спрогнозувати діагноз» з
39
усіх вірогідних хворіб визначається захворювання з найбільшою ймовірністю,
яке і є встановленим діагнозом.

процесу «Встановити діагноз»
Декомпозиція процесу «Надати рекомендації» зображено на рис. 3.16. Він
розбивається на підпроцеси «Підібрати лікування», в якому відповідно до
встановленого діагнозу та інформації про лікування, яку надав лікар, формується
рецепт у вигляді препаратів та особливості їх прийому; та «Сформувати дані для
надання рекомендацій», в якому формується вся консультаційна інформація
щодо діагнозу та призначеного лікування і надсилається пацієнту.

процесу «Надати рекомендації»
40
Процес «Налаштувати нагадування» (рис. 3.17) деталізується на підпроцеси
«Встановити курс лікування», «Активувати сповіщення» та «Сформувати
історію нагадувань». Процес «Встановити курс лікування» приймає введені
параметри нагадування і надсилає наступному підпроцесу «Активувати
сповіщення» дату, час, текст і дозування нагадування. Після того, як користувач
отримає сповіщення про прийом ліків, воно буде записане в історію нагадувань,
за що й відповідає підпроцес «Сформувати історію нагадувань».

процесу «Налаштувати нагадування»

2. Визначити зовнішні сутності, процеси, накопичувані даних, потоки
даних; описати їх призначення у вигляді таблиці.
3. Відповідно до індивідуального завдання побудувати діаграму потоків
даних (DFD) в нотації Гейна-Сарсона.
4. Побудувати діаграми декомпозиції відповідно до індивідуального
завдання
1. Призначення контекстної діаграми
2. Поняття зовнішньої сутності та процесу на DF діаграмі
3. Яка нотація використовується для побудови діаграм потоків даних в
середовищі AllFusion
4. Зображення зовнішніх сутностей та сховищ даних на DFD
41
Створення діаграм дерева вузлів та FEO (For Exposition Only)

інтегрованих систем та навчитись будувати діаграми дерева вузлів та тільки для
експозиції (For Exposition Only).
Діаграма дерева вузлів показує ієрархію процесів в моделі і дозволяє
розглянути всю модель загалом, але не показує взаємозв'язку між процесами.
Оскільки створення моделі процесів є ітераційним, тому останні можуть
змінювати своє розташування в дереві вузлів багаторазово. Щоб не заплутатися
і перевірити спосіб декомпозиції, необхідно після кожної зміни створювати
діаграму дерева вузлів. Особливістю середовища AllFusion є наявність
потужного інструменту навігації по моделі – Model Explorer, який дозволяє
представити ієрархію процесів в зручному і компактному вигляді, проте цей
інструмент не є складовою стандарту IDEF0.
Для створення діаграми дерева вузлів необхідно вибрати в меню пункт
Diagram / Add Node Tree. В результаті чого з’являється майстер створення
діаграми дерева вузлів Wizard Tree Node. В першому діалозі необхідно ввести
назву діаграми вузлів, вузла верхнього рівня та глибини дерева – кількість рівнів
(по замовчуванню 3). В одній моделі можна створювати множину діаграм дерева
вузлів. Назва дерева вузлів по замовчуванню співпадає з назвою процесу
верхнього рівня, а номер діаграми автоматично генерується як номер вузла
верхнього рівня плюс літера "N", наприклад A0N. Якщо в моделі з'єднується два
дерева вузлів, що мають в якості верхнього рівня один і той же процес, то по
замовчуванню діаграми отримають ідентичні номери та назву. Тому
рекомендується при створенні діаграм дерева вузлів ввести назву діаграми, що
буде відмінною від значення по замовчуванню. Другий діалог майстра Node Tree
Wizard (рис4.1.) дозволяє задавати властивості діаграми дерева вузлів.
По замовчуванню, нижній рівень декомпозиції відображається у вигляді
списку, решта процесів – у вигляді прямокутників. Для відображення всього
дерева у вигляді прямокутників потрібно вибрати опцію Bullet Last Level. Група
Connection Style дозволяє вибрати стиль з’єднувальних ліній – діагональні (по
замовчуванню) або ортогональні.
На початку виконання необхідно обрати пункт головного меню
Diagram/Add Node Tree і у вікні майстра Node Tree Wizard внести назву діаграми,
вказати діаграму кореня дерева і кількість рівнів (рис. 4.2) та натиснути кнопку
"Next" для продовження роботи.
42
Рис. 4.1. Діалог налаштування діаграми дерева вузлів
Рис. 4.2. Перше діалогове вікно майстра Node Tree Wizard
43
У другому діалоговому вікні майстра Node Tree Wizard залишимо
параметри без змін. Далі необхідно клацнути по кнопці Finish і в результаті буде
створена діаграма дерева вузлів (Node tree Diagram) (рис.4.3).
Рис.4.3. Діаграма дерева вузлів

Модифікуємо діаграму дерева вузлів шляхом відображення нижнього
рівня не у вигляді списку, а у вигляді прямокутників, так само, як і верхні рівні.
Для модифікації діаграми правою кнопкою миші необхідно клацнути по
вільному місцю, що не зайнятий об'єктами та вибрати команду меню Node tree
Diagram Properties і у вкладці Style діалогу Node Tree Properties вимкнути опцію
Bullet Last Level (рис. 4.4).
Рис.4.4. Результат виконання
44
Діаграми FEO
Діаграми "тільки для експозиції" (FEO) часто використовуються як моделі
для відображення інших точок зору, окремих деталей, які явно не підтримуються
синтаксисом IDEF0. Діаграми FEO дозволяють порушити будь-яке синтаксичне
правило, оскільки являються звичайними зображеннями-копіями стандартних
діаграм і не включаються в аналіз синтаксису. Наприклад, процес на діаграмі
FEO може не мати стрілок управління і виходу. Зокрема, з метою обговорення
певних аспектів моделі з експертом предметної області може бути створена
діаграма тільки з одним процесом і однією стрілкою, оскільки стандартна
діаграма декомпозиції містить множину деталей, що не відносяться до теми
обговорення і можуть дезорієнтувати експерта. Проте, якщо FEO
використовується для відображення альтернативних точок зору (альтернативний
контекст), рекомендується все-таки дотримуватися синтаксису IDEF0. Для
створення діаграми FEO необхідно вибрати пункт меню Diagram / Add FEO
Diagram. У створеному діалозі Add New FEO Diagram необхідно вказати назву
діаграми FEO і тип батьківської діаграми. Нова діаграма отримує номер, який
генерується автоматично (номер батьківської діаграми по вузлу + постфікс F,
наприклад A1F).
Припустимо, що під час обговорення бізнес-процесів виникла необхідність
детально розглянути взаємодію процесу " Здійснити збирання комп'ютерів " з
іншими процесами. Щоб не «псувати діаграму декомпозиції» необхідно
створити FEO-діаграму, на якій будуть лише стрілки процесу "Здійснити
збирання комп'ютерів".
Для проектування даної діаграми необхідно вибрати пункт головного
меню Diagram/Add FEO Diagram. Далі в діалоговому вікні Add New FEO Diagram
вибрати тип і заповнити назву діаграми FEO, як показано на рис.4.5.
Рис. 4.5. Діалогове вікно Add New FEO Diagram
45
З допомогою клавіші Delete необхідно видалити зайві стрілки на діаграмі
FEO. Результат показано на рис. 4.6.
Рис. 4.6. Діаграма FEO

Для переходу між стандартною діаграмою, деревом вузлів та FEO
необхідно використовувати кнопку на палітрі інструментів .

2. Використовуючи наведений приклад, побудувати діаграму дерева вузлів
відповідно до індивідуального завдання та проекспериментувати із варіантами її
відображення
3. Побудувати діаграму FEO з метою її демонстрації експерту із визначеної
предметної області. Підготувати по ній 15 запитань, на які дати аргументовані
відповіді, що стосуються функціонування визначеного процесу системи.
1. Поняття діаграми дерева вузлів та особливості створення
2. Призначення діаграми FEO та порядок її побудови
3. Особливості модифікації графічного представлення діаграми дерева вузлів
4. Перемикання між стандартними діаграмами та дерева вузлів й FEO
46
Створення workflow діаграми в стандарті IDEF3

інтегрованих систем та навчитись будувати діаграми в стандарті IDEF3 та
здійснювати побудову сценаріїв.
Для опису логіки взаємодії інформаційних потоків за звичай доцільно
застосовувати методологію IDEF3, яку часто називають workflow diagramming -
методологією моделювання, що використовує графічний опис інформаційних
потоків, взаємовідношення між роботами з обробки інформації та об'єктів, які є
частиною цих робіт. Діаграми Workflow можуть бути використані при
моделюванні бізнес-процесів для аналізу завершеності процедур обробки
інформації. З їх допомогою можна описувати сценарії дій співробітників
компанії, наприклад послідовність обробки замовлення або події, які необхідно
опрацювати за визначений час. Кожен сценарій супроводжується описом роботи
і може бути використаний для документування кожної функції.
Основною метою IDEF3 є надання аналітикам механізму опису ситуації, у
випадку коли роботи виконуються у визначеній послідовності, а також
можливості із опису об’єктів які спільно працюють. Техніка опису набору даних
IDEF3 є частиною структурного аналізу. На відміну від деяких методик-описів
робіт IDEF3 не обмежує аналітика надмірно жорсткими рамками синтаксису, що
може привести до створення неповних або суперечливих моделей.
IDEF3 доповнює IDEF0 і містить все необхідне для побудови моделей, які
в подальшому можуть бути використані для імітаційного аналізу. Кожна робота
в IDEF3 описує будь-якої сценарій бізнес-процесу і може бути складовою іншої
роботи. Оскільки сценарій описує мету і границі моделі, важливо, щоб роботи
найменувалися віддієслівними іменниками, що позначають процес дії, або
іменним словосполученням, що містить такий іменник.
Точка зору на модель повинна бути задокументована. Зазвичай це точка
зору людини, що є відповідальною за роботу в цілому. Також необхідно
задокументувати мету побудови моделі – питання, на які повинна відповісти
модель.
Діаграми. Діаграма є основною одиницею опису в IDEF3. Важливо
правильно побудувати діаграми, оскільки вони призначені для читання іншими
людьми, а не тільки автором.
Одиниці роботи - Unit of Work (UOW), також часто називають
діяльностями (activity), є центральними компонентами моделі. У IDEF3 вони
зображуються прямокутниками з прямими кутами і мають назву, що позначає
процес дії і номер (ідентифікатор). Часто назва діяльності в імені роботи
47
змінюється в процесі моделювання, оскільки модель може уточнюватися і
редагуватися. При цьому ідентифікатор роботи який присвоюється при
створенні не змінюється ніколи. Навіть якщо робота буде видалена, її
ідентифікатор не зможе бути використаний для інших робіт. Зазвичай номер
роботи складається з номера батьківської роботи і порядкового номера на
поточній діаграмі.
Робота в IDEF3 вимагає більш детального опису, ніж процес в IDEF0.
Кожна UOW повинна мати асоційований документ, який включає текстовий опис
компонентів роботи: об'єктів (Objects) і фактів (Facts), пов'язаних з нею,
обмежень (Constraints), що накладаються, і додатковий опис (Description). Ця
інформація заноситься на вкладку UOW діалогу Activity Properties. Приклад
значень властивостей UOW наведено в табл. 5.1.
Табл.5.1. Приклад текстового опису компонентів UOW
Тип Використання
Name Підготувати комплектуючі
Підготувати всі комплектуючі комп'ютера згідно специфікації
Definition замовлення
Комплектуючі: вінчестер, корпус, материнська плата, відеокарта,
Objects звукова карта, програмне забезпечення
Встановлення відеокарти потребує додаткового програмного
Constrains забезпечення
Зв'язки показують взаємовідношення між роботами. Всі зв'язки в IDEF3

одно направлені і можуть бути спрямовані куди завгодно, але зазвичай діаграми
IDEF3 будуть таким чином, щоб зв'язки були спрямовані зліва направо. В IDEF3
розрізняють три типи стрілок, що відображають зв'язки, стиль яких
встановлюється на вкладці Style діалогу Arrow Properties (пункт контекстного
меню Style).
Пріоритетна (старша) (Precedence) стрілка – суцільна лінія, що зв'язує
одиниці роботи (UOW). Рисується зліва направо або зверху вниз. Показує, що
робота-джерело повинна закінчитися раніше, ніж розпочнеться робота-мета.
Стрілка відношення (Relational Link) – пунктирна лінія, що
використовується для зображення зв'язків між одиницями робіт (UOW), а також
між одиницями робіт і об'єктами посилань.
Потоки об'єктів (Object Flow) – стрілка з двома наконечниками,
застосовується для опису того факту, що об'єкт використовується в двох або
більше одиницях робіт, наприклад, коли об'єкт породжується в одній роботі і
використовується в іншій.
48
Рис. 5.1. Вкладка Style діалогу Arrow Properties
Пріоритетний зв'язок і потік об’єктів. Часто результатом роботи-джерела
стає об'єкт, необхідний для запуску роботи-мети. В цьому випадку стрілку, що
позначає об'єкт, зображують з подвійним наконечником. Назва стрілки повинна
однозначно ідентифікувати об'єкт, що відображається. Потік об'єктів має ту ж
семантику, що і пріоритетна стрілка.
Відношення показує, що стрілка є альтернативою пріоритетній стрілці або
потоку об'єктів в сенсі завдання послідовності виконання робіт. Робота-джерело
не обов'язково повинна закінчитися раніше, ніж розпочнеться робота-мета.
Більш того, робота-мета може закінчитися раніше, ніж закінчиться робота-
джерело (рис. 5.2.).
Початок Закінчення Початок Закінчення
Пріоритетний
роботи-джерела роботи-джерела роботи-мети роботи-мети
зв язок чи потік
об єктів
Початок Початок Закінчення Закінчення
роботи-джерела роботи-мети роботи-джерела роботи-мети
Відношення
Початок Початок Закінчення Закінчення

роботи-джерела роботи-мети роботи-мети роботи-джерела
Відношення
Рис. 5.2. Часова діаграма виконання робіт

Перехрестки. Закінчення однієї роботи може служити сигналом до початку
декількох інших, або ж одна робота для свого запуску може очікувати закінчення
декількох інших робіт. Перехрестки використовуються для відображення логіки
взаємодії стрілок під час з'єднання та розгалуження або для відображення
49
множинних подій, які можуть або повинні бути завершені перед початком
наступної роботи. Розрізняють перехрестки для злиття (Fan–in Junction) і
розгалуження (Fan–out Junction) стрілок. Перехресток не може одночасно
використовуватися для злиття та розгалуження. Для додання перехрестя служить
кнопка (додати в діаграму перехрестя - Junction) в палітрі інструментів. В
діалозі Junction Type Editor необхідно ввести тип перехрестя. Призначення
кожного типу перехрестя наведено в табл. 5.2.
Табл.5.2. Таблиця перехресть
Піктограма Найменування Призначення у випадку Призначення у випадку
злиття стрілок (Fan-in розгалуження стрілок
Junction) (Fan-out Junction)
Asynchronous Всі попередні процеси Всі наступні процеси
AND повинні бути завершені повинні бути запущені
Synchronous Всі попередні процеси Всі наступні процеси
AND завершені одночасно запускаються одночасно
Asynchronous Один або декілька Один або декілька
OR попередніх процесів наступних процесів
повинні бути завершені повинні бути запущені
Synchronous Один або декілька Один або кілька
OR попередніх процесів наступних процесів
завершуються запускаються одночасно
одночасно
XOR (Exclusive Тільки один Тільки один наступний
OR) попередній процес процес запускається
завершений
Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J.

Можна редагувати властивості перехрестя за допомогою діалогу Junction
Properties (викликається з контекстного меню). На відміну від IDEF0 і DFD в
IDEF3 стрілки можуть зливатися і розгалужуватися тільки через перехрестя.
Подальші рисунки ілюструють зміст перехресть кожного типу.
50
Рис.5.3. Перехрестя для злиття і розгалуження типу синхронного "І"
Тут після завершення роботи 1 одночасно запускаються роботи 2 і 4. Для
запуску роботи 5 потрібне одночасне завершення робіт 3 та 4.
Рис.5.4. Перехрестя для злиття і розгалуження типу асинхронного "І"

Тут після завершення роботи 1 запускаються роботи 2 і 4 (не обов'язково
одночасно). Для запуску роботи 5 потрібно завершення робіт 3 та 4 (не
обов'язково одночасне).
Рис.5.5. Перехрестя для злиття і розгалуження типу асинхронного "АБО"
51
Тут після завершення роботи 1 запускається або робота 2, або робота 3, або
робота 4, або їх поєднання (не обов'язково одночасно). Для запуску роботи 5
потрібне завершення будь-якої з робіт 2, 3 і 4 або їх поєднання (не обов'язково
одночасне).
Рис. 5.6. Перехрестя для злиття і розгалуження типу синхронного "АБО"

Тут після завершення роботи 1 запускається або робота 2, або робота 3, або
робота 4, або їх поєднання. Якщо запускається більше однієї роботи, потрібно
здійснити їх одночасний запуск. Для запуску роботи 5 потрібне завершення
будь-якої з робіт 2, 3 і 4 або їх поєднання. Якщо завершується більш ніж одна
робота, то потрібне їх одночасне завершення.
Рис.5.7. Перехрестя із застосуванням виключного «АБО»

Тут після завершення роботи 1 запускається тільки одна робота, або робота
2, або робота 4. Для запуску роботи 5 потрібно завершення тільки однієї з робіт,
3 або 4
Правила створення перехресть. На одній діаграмі IDEF3 може бути
створено кілька перехресть різних типів. Певні поєднання перехресть для злиття
і розгалуження можуть призводити до логічних невідповідностей. Щоб уникнути
конфліктів, необхідно дотримуватися таких правил:
52
1. Кожному перехрестя для злиття повинно передувати перехрестя для
розгалуження.
2. Перехрестя для злиття "І" не може слідувати за перехрестям для
розгалуження типу синхронного або асинхронного "АБО". Дійсно, після роботи
1 може запускатися тільки одна робота - 2 або 3, а для запуску роботи 4 потрібне
закінчення обох робіт - 2 і 3. Такий сценарій не може реалізуватися.
Рис.5.8. Неправильне розміщення перехресть.

Перехрестя для злиття "І" не може слідувати за перехрестям для
розгалуження "АБО"
3. Перехрестя для злиття "І" не може слідувати за перехрестям для
розгалуження типу виключне "АБО".
Рис. 5.9. Неправильне розміщення перехресть

Перехрестя для злиття "І" не може слідувати за перехрестям для
розгалуження типу виключне "АБО".
4. Перехрестя для злиття типу виключне "АБО" не може слідувати за
перехрестям для розгалуження типу виключне "І" Тут після завершення роботи
1 запускаються обидві роботи - 2 і 3, а для запуску роботи 4 потрібно, щоб
завершилась одна і тільки одна робота - або 2, або 3.
53
Рис.5.10. Неправильне розміщення перехресть.
Перехрестя для злиття "АБО" не може слідувати за перехрестям для
розгалуження типу, що виключне "І"
5. Перехрестя, що має одну стрілку на одній стороні, повинно мати більше
однієї стрілки на іншій.
Об'єкт посилання. Об'єкт посилання в IDEF3 виражає якусь ідею,
концепцію або дані, які не можна пов'язати зі стрілкою, перехрестям або
роботою. Для додання об'єкта посилання служить кнопка (додати в діаграму
об'єкт посилання – Referent) на палітрі інструментів. Об'єкт посилання
зображується у вигляді прямокутника, що схожий на прямокутник роботи.
Назва об'єкта посилання задається в діалозі Referent Properties (пункт
контекстного меню Name), в якості назви можна використовувати ім'я будь-якої
стрілки з інших діаграм або ім'я сутності з моделі даних. Об'єкти посилання
повинні бути пов'язані з одиницями робіт або перехрестями пунктирними
лініями. Офіційна специфікація IDEF3 розрізняє три стилі об'єктів посилань -
безумовні (unconditional), синхронні (synchronous) і асинхронні (asynchronous).
AllFusion підтримує тільки безумовні об'єкти посилань. Синхронні та асинхронні
об'єкти посилань, які використовуються в діаграмах переходів станів об'єктів, не
підтримуються. При внесенні об'єктів посилань крім назви необхідно вказувати
тип об'єкта посилання. Типи об'єктів посилань наведені в табл. 5.3.
Табл.5.3. Типи об’єктів посилань
Тип об’єкта Мета опису
посилань
OBJECT Описує участь важливого об'єкта в роботі
GOTO Інструмент циклічного переходу (в повторюваній послідовності
робіт), можливо на поточній діаграмі, але не обов'язково. Якщо всі
роботи циклу присутні на поточній діаграмі, цикл може також
зображатися стрілкою, що повертається на запуск. GOTO може
посилатися на перехрестя
54
UOB (Unit Застосовується, коли необхідно підкреслити множинне використання
of behavior) будь-якої роботи, але без циклу. Наприклад, робота "Контролювати
якість" може бути використана в процесі "Виготовити виріб" кілька
разів, після кожної одиничної операції. Зазвичай цей тип посилання
не використовується для моделювання робіт які автоматично
запускаються
NOTE Застосовується для документування важливої інформації, що
відноситься до будь-яких графічних об'єктів на діаграмі. NOTE є
альтернативою внесенню текстового об'єкта в діаграму
ELAB Використовується для удосконалення графіків або їх більш
(Elabora- детального опису. Зазвичай вживається для детального опису
tion) розгалуження і злиття стрілок на перехрестях
Декомпозиція робіт. У IDEF3 декомпозиція використовується для

деталізації робіт. Методологія IDEF3 дозволяє багаторазово здійснити
декомпозицію роботи, що дозволяє в одній моделі описати альтернативні
потоки. Декомпозиція може бути сценарієм або описом. Опис включає всі
можливі шляхи розвитку процесу. Сценарій є окремим випадком опису та
ілюструє тільки один шлях реалізації процесу. По замовчуванню при
декомпозиції на діаграмі IDEF3 створюється опис. Щоб створити сценарій,
необхідно перейти в меню Diagram/Add IDEF3 Scenario.
Можливість множинної декомпозиції висуває додаткові вимоги до
нумерації, а саме починається з номера батьківської роботи, номера декомпозиції
і власного номера роботи на поточній діаграмі робіт (рис. 5.11).
Рис.5.11. Номер одиниці роботи (UOW)

Для опису номер декомпозиції дорівнює одиниці. Для сценарію номер
декомпозиції завжди більший за одиницю. При створенні сценарію або опису
необхідно дотримуватися додаткових обмежень - в сценарії або декомпозиції
може існувати тільки одна точка входу. За точкою входу розміщується робота
або перехрестя. При декомпозиції може існувати тільки одна точка виходу.
Сценарій, який не є декомпозицією, може мати кілька точок виходу. Розглянемо
процес декомпозиції діаграм IDEF3, що включає взаємодію автора (аналітика) і
одного або декількох експертів предметної області.
Опис сценарію, області та точки зору. Перед проведенням сеансу
експертизи у експертів предметної області повинні бути задокументовані
55
сценарії і рамки моделі для того, щоб експерт міг зрозуміти цілі декомпозиції.
Крім того, якщо точка зору моделювання відрізняється від точки зору експерта,
вона повинна бути особливо ретельно задокументована.
Можливо, що експерт самостійно не зможе передати необхідну
інформацію. В цьому випадку аналітик повинен приготувати список питань для
проведення інтерв'ю.
Визначення робіт і об'єктів. Зазвичай експерт предметної області передає
аналітику текстовий опис сценарію. Крім того, може існувати документація, що
описує відповідні процеси. З усієї цієї інформації аналітик повинен скласти
список кандидатів на роботи (віддієслівні іменники, що позначають процес,
поодинокі або в складі іменного словосполучення) і кандидатів на об'єкти
(іменники, що позначають результат виконання роботи), які необхідні для
перерахованих у списку робіт.
У деяких випадках доцільно створити графічну модель для представлення
її експерту предметної області. Графічна модель може бути також створена після
сеансу збору інформації для того, щоб деталі форматування діаграми не
бентежили учасників.
Оскільки різні фрагменти моделі IDEF3 можуть бути створені різними
групами аналітиків в різний час, IDEF3 підтримує просту схему нумерації робіт
в рамках всієї моделі. Різні аналітики оперують різними діапазонами номерів,
працюючи при цьому незалежно. Приклад виділення діапазону наведено в табл.
5.3.
Табл.5.3. Діапазони номерів робіт
Аналітик Діапазон номерів IDEF3
Петренко 1–999
Іваненко 1000–1999
Сидоренко 2000–2999
Послідовність і узгодження. Якщо діаграма створюється після проведення
інтерв'ю, аналітик повинен прийняти деякі рішення, що відносяться до ієрархії
діаграм, наприклад, визначити, скільки деталей включати в одну діаграму. Якщо
послідовність і узгодження діаграм неочевидні, може бути проведена ще одна
експертиза для деталізації і уточнення інформації. Роботи, перехрестя і
документування об'єктів. IDEF3 дозволяє внести інформацію в модель різними
способами. Наприклад, логіка взаємодії може бути відображена графічно у
вигляді комбінації перехресть. Та ж інформація може бути відображена у вигляді
об'єкта посилання типу ELAB (Elaboration). Це дозволяє аналітику вносити
інформацію в зручному в даний момент часу вигляді. Важливо враховувати, що
моделі можуть бути реорганізовані, наприклад, для їх подання в більш
презентабельному вигляді. Вибір формату для презентації часто має важливе
значення для організації моделі, оскільки комбінація перехресть займає значне
56
місце на діаграмі і використання ієрархії перехресть ускладнює розташування
робіт на діаграмі. Для прикладу здійснимо декомпозицію процесу «Здійснити
складання настільних комп’ютерів» на діаграмі А2.
Рис. 5.12. Діаграма А2 з об’єктом декомпозиції

В діалозі Activity Box Count необхідно встановити кількість робіт- 4 і
нотацію IDEF3.
Рис. 5.13. Вибір нотації IDEF3 в діалозі Activity Box Count

З’являється діаграма IDEF3, що містить роботи Unit of Work (UOW), які
також носять назву одиниці робіт. Правою кнопкою миші по роботі з номером 1,
необхідно вибрати контекстному меню Name і внести назву роботи "Підготувати
комплектуючі". Далі на вкладці Definition потрібно внести визначення роботи
"Підготовка всіх комплектуючих комп'ютера згідно специфікації замовлення".
На вкладці UOW діалогового вікна Activity Properties необхідно внести
властивості роботи 1 у відповідності із даними:
57
• Objects – комплектуючі: вінчестер, корпус, материнська плата, відеокарта,
пам‘ять, звукова карта, програмне забезпечення
• Facts – доступні операційні системи
• Constrains – встановлення відеокарти вимагає додаткового програмного
забезпечення
Додати до діаграми ще 3 роботи і присвоїти їм назви: 2- встановити
материнську плату та вінчестер, 3 – встановити відеокарту, 4 – встановити
пам’ять, 5 – встановити звукову карту, 6 – встановити операційну систему, 7 –
встановити додаткове програмне забезпечення (рис.5.14).
Рис.5.14. Діаграма IDEF3 після присвоєння назв роботам

Далі необхідно додати об’єкт посилання із назвою Комплектуючі і
з’єднати його стрілкою з роботою "Підготувати комплектуючі". Здійснити
зміну стилю стрілки на Referent, скориставшись діалоговим вікном Arrow
Properties.
Рис.5.15. Поєднання об’єкту посилання та роботи
58
Пов’язати стрілкою роботи "Підготувати комплектуючі" (вихід) і
"Встановити материнську плату і вінчестер" (вхід) та змінити стиль стрілки на
Object Flow. Згідно із стандартом на діаграмах IDEF3 назва стрілки може бути
відсутньою, хоча система відображає відсутність назви як помилку. Додамо на
діаграму два перехрестя типу “асинхронне АБО” і з’єднаємо їх з роботами
(рис.5.16).
Рис.5.16. Діаграма IDEF3 після створення перехресть
Правою кнопкою миші на перехресті розгалуження J1 (fan-out), вибрати

опцію Name та вписати "Компоненти, необхідні в специфікації замовлення". Далі
необхідно додати ще один об'єкт посилання з назвою "Програмне забезпечення"
та створити два перехрестя типу "виключне АБО" (рис.5.17).
59
Рис.5.17 Результат виконання роботи
Створення сценарію
Сценарії зручно створювати для випадку графічного відображення
частини робіт системи для подальшого діалогу із експертом.
Для створення нового сценарію необхідно скористатись командою:
Diagram/Add IDEF3 Scenario. Побудуємо діаграму сценарію на основі діаграми
IDEF3 "Здійснити складання настільних комп’ютерів" (А22.1), задавши
параметри у відповідності із рис.5.18.
Рис. 5.18. Параметри сценарію
60
Створена діаграма матиме вид представлений на рис.5.19.
Рис.5.18. Проект сценарію

Здійснимо видалення об’єктів, які не входять в сценарій.
Рис.5.19 Завершений сценарій роботи
61
2. Використовуючи наведений приклад, побудувати діаграму узгодженої з
викладачем предметної області в стандарті IDEF3.
3. Описати всі роботи системи та пояснити використання різних типів перехресть
на власній діаграмі
4. Здійснити побудову сценарію роботи та підготувати 10 можливих запитань та
відповідей експерта по ньому. Запитання не повинні співпадати з попередньою
роботою
1. Поняття workflow діаграми та її призначення
2. Порядок побудови workflow діаграми в IDEF3
3. Поняття та типи перехресть в IDEF3
4. Поняття сценарію та особливості його побудови
62
Лабораторна робота №6
Вартісний аналіз проекту в AllFusion Process Modeler
Мета роботи – ознайомитись з основними принципами проведення вартісного

аналізу та здійснити генерацію звіту в системі AllFusion
На практиці, зазвичай спочатку будується функціональна модель існуючої
організації роботи - AS-IS (Як є). Після побудови моделі AS-IS проводиться
аналіз бізнес-процесів, потоки даних і об'єктів перенаправляються і
покращуються, в результаті будується модель ТО-ВЕ. Як правило, будується
кілька моделей ТО-ВЕ, з яких по певному критерію вибирається найкраща.
Проблема полягає в тому, що існує множина критеріїв і важко вибрати
найкращий. Для визначення якості створеної моделі з точки зору ефективності
бізнес-процесів, необхідна система метрики, тобто якість, слід оцінювати
кількісно. AllFusion надає аналітику два інструменти для оцінки моделі –
вартісний аналіз, побудований на роботах (Activity Based Costing, ABC), і
властивості, що визначаються користувачем (User Defined Properties, UDP). ABC
є поширеною методикою, яка використовується міжнародними корпораціями та
державними організаціями (в тому числі Департаментом оборони США) для
ідентифікації справжніх чинників витрат організації.
Вартісний аналіз, що являє собою угоду про облік, що використовується
для збору витрат, пов'язаних з роботами, з метою визначення загальної вартості
процесу. Вартісний аналіз побудований на моделі робіт, тому що кількісна
оцінка неможлива без детального розуміння функціональності підприємства.
Зазвичай ABC застосовується для того, щоб зрозуміти походження вихідних
витрат і полегшити вибір потрібної моделі робіт при реорганізації діяльності
підприємства (Business Process Reengineering, BPR).
За допомогою вартісного аналізу можна вирішити такі завдання, як
визначення дійсної вартості виробництва продукту, визначення дійсної вартості
підтримки клієнта, визначення робіт, які вартують більше за все (ті, які повинні
бути покращені в першу чергу), забезпечення менеджерів фінансової мірою
пропонованих вимірювань.
ABC може проводитися тільки тоді, коли модель роботи:
1. послідовна (слідує синтаксичним правилам IDEF0)
2. коректна (відображає бізнес)
3. повна (охоплює всю розглянуту область)
4. стабільна (проходить цикл експертизи без змін), іншими словами, коли
створення моделі роботи закінчено.
ABC включає наступні основні поняття:
63
• об'єкт витрат - причина, по якій робота виконується;
зазвичай основний вихід роботи, вартість робіт - є сумарна вартість
об'єктів витрат "Готовий виріб", рис. 6.1).
• рушій витрат - характеристики входів та управлінь роботи
("Сировина", "Креслення", рис. 6.1), які впливають на те, як виконується і
як довго триває робота;
• центри витрат, які можна трактувати як статті витрат.
Рис.6.1. Ілюстрація термінів ABC

При проведенні вартісного аналізу в AllFusion спочатку задаються
одиниці виміру часу і грошей. Для завдання одиниць вимірювання слід
викликати діалог Model Properties (меню Model / Model Properties), вкладка ABC
Units. Якщо в списку вибору відсутня необхідна валюта (наприклад, гривня), її
можна додати. Діапазон вимірювання часу в списку Unit of measurment достатній
для більшості випадків - від секунд до років.
Потім описуються центри витрат (cost centers). Для внесення центрів
витрат необхідно викликати діалог Cost Center Dictionary (меню Dictionary / Cost
Center (рис. 120). Кожному центру витрат слід дати докладний опис у вікні
Definition. Список центрів витрат впорядкований. Порядок в списку можна
змінювати за допомогою стрілок, розташованих праворуч від списку. Завдання
певної послідовності центрів витрат в списку, по-перше, полегшує подальшу
роботу в процесі присвоєння вартості робіт, а по-друге, має значення при
використанні єдиних стандартних звітів в різних моделях. Хоча AllFusion
зберігає інформацію про стандартний звіт в файлі BPWINRPT.INI, інформація
про центри витрат і UDP зберігаються у вигляді покажчиків, тобто зберігаються
не назви центрів витрат, а їх номери. Тому, якщо потрібно використовувати один
і той же стандартний звіт в різних моделях, списки центрів витрат повинні бути
в них однакові.
Для завдання вартості роботи (для кожної роботи на діаграмі декомпозиції)
необхідно натиснути правою кнопкою миші по роботі і в спливаючому меню
64
вибрати Costs (рис. 6.2). У вкладці Costs діалогу Activity Properties вказується
частота проведення даної роботи в рамках загального процесу (Frequency) і
тривалість (Duration). Потім слід вибрати в списку один із центрів затрат і в вікні
Cost задати його вартість. Аналогічно призначаються суми по кожному центру
витрат, тобто задається вартість кожної роботи по кожній статті витрат. Якщо в
процесі призначення вартості виникає необхідність внесення додаткових центрів
витрат, то діалог Cost Center Editor викликається прямо з діалогу Activity Cost
відповідною кнопкою.
Рис.6.2. Завдання вартості робіт в діалозі Activity Cost

Загальні витрати розраховуються як сума по всіх центрах витрат. При
обчисленні витрат вищестоящої (батьківської) роботи спочатку обчислюється
добуток витрат дочірньої роботи на частоту роботи (кількість раз, що робота
виконується в рамках проведення батьківської роботи), потім результати
сумуються. Якщо у всіх роботах моделі включений режим Compute from
Decompositions, подібні обчислення автоматично проводяться по всій ієрархії
робіт від низу до верху.
Цей досить спрощений принцип підрахунку є доцільний якщо роботи
виконуються послідовно. Вбудовані можливості програми дозволяють
розробляти спрощені моделі вартості, які, тим не менш, є надзвичайно
корисними для попередньої оцінки витрат. Якщо схема виконання більш складна
(наприклад, роботи проводяться альтернативно), можна відмовитися від
підрахунку і задати підсумкові суми для кожної роботи вручну (Override
65
Decompositions). У цьому випадку результати розрахунків з нижніх рівнів
декомпозиції будуть ігноруватися, при розрахунках на верхніх рівнях буде
враховуватися сума, визначена вручну. На будь-якому рівні результати
розрахунків зберігаються незалежно від обраного режиму, тому при виключенні
опції Override Decompositions розрахунок від низу до верху проводиться за
звичайною схемою.
Для проведення більш тонкого аналізу можна скористатися спеціалізованим
засобом вартісного аналізу EasyABC (ABC Technology, Inc.). AllFusion має
двонаправлений інтерфейс з EasyABC. Результати вартісного аналізу можуть
істотно вплинути на черговість виконання робіт. Розглянемо приклад, який
представлений на рис.6.3. Припустимо, що для оцінки якості виробу необхідно
провести три роботи:
• здійснити зовнішній огляд - вартість 50 грн.;
• здійснити пробне включення - вартість 150 грн .;
• провести випробування на стенді - вартість 300 грн.
Припустимо також, що з точки зору технології черговість проведення робіт
несуттєва, а ймовірність виявлення браку однакова (50%). Нехай необхідно
перевірити вісім виробів.
1) Якщо проводити роботи в спадному по вартості порядку, то вартість,
витрачена на отримання готового виробу, складе:
300 грн. (провести випробування на стенді) * 8 + 150 грн. (здійснити пробне
включення) * 4 + 50 грн. (здійснити зовнішній огляд) * 2 = 3100 грн.
2) Якщо проводити роботи в зростаючому по вартості порядку, то вартість,
витрачена на отримання готового виробу, складе:
50 грн. (здійснити зовнішній огляд) * 8 + 150 грн. (здійснити пробне включення)
* 4 + 300 грн (провести випробування на стенді) * 2 = 1600 грн.
Отже, з метою мінімізації витрат першою повинна бути виконана
найдешевша робота, потім - середня за вартістю і в кінці - найдорожча (рис. 6.3).
Рис. 6.3. Фрагмент діаграми декомпозиції процесу "Контролювати якість "
66
Результати вартісного аналізу наочно представляються в спеціальному
звіті AllFusion - Activity Cost Report (меню Tools / Report / Activity Cost Report).
Звіт дозволяє документувати назву, номер та вартість робіт, як сумарну, так і
окрему по центрам витрат.
Результати відображаються і безпосередньо на діаграмах. У лівому
нижньому кутку прямокутника може відображатися або вартість (по
замовчуванню), або тривалість, або частота проведення. Налаштування
відображення здійснюється в діалозі Model Properties (меню Model / Model
Properties), вкладка Display, опції ABC Data і ABC Units.
Методика виконання завдання

У діалоговому вікні Model Properties (викликається з меню Mode / Model
Properties) на вкладці ABC Units (рис. 6.4) необхідно встановити одиниці виміру
грошей – гривні і часу - годинник.
Рис. 6.4. Вкладка ABC Units діалогу Model Properties

Для відображення вартості кожної роботи в нижньому лівому кутку
прямокутника необхідно перейти в меню Model / Model Properties і на вкладці
Display діалогу Model Properties включити опцію ABC Data (рис. 6.5). Для
відображення частоти або тривалості роботи необхідно перейти між радіо
кнопками в групі ABC Units.
67
Рис.6.5. Вкладка Display діалогу Model Properties
Для завдання вартості роботи "Здійснити складання настільних
комп‘ютерів " необхідно на діаграмі А2 натиснути правою кнопкою миші по
роботі і в спливаючому меню вибрати Costs (рис. 6.2.). У вкладці Costs діалогу
Activity Properties необхідно вказати частота проведення даної роботи в рамках
загального процесу (Frequency) і тривалість (Duration). Для робіт на діаграмі А2
необхідно внести такі параметри ABC (табл.6.1)
Табл.6.1. Показники вартості робіт на діаграмі А2
Activity Name Cost Center Cost Center Duration, Frequency
Cost, грн. година
Відстежити розклад та Управління 500,00 0,50 14,00
керувати збиранням і
Здійснити складання Робоча сила 100,00 2,00 8,00
настільних комп'ютерів Комплектуючі 16000,00
Здійснити складання Робоча сила 140,00 4,00 6,00
ноутбуків Комплектуючі 28000,00
Провести тестування Робоча сила 60,00 1,00 14,00
Після проведених дій в лівому нижньому кутку процесу
відображатиметься вартість робіт (рис.6.6).
68
Рис.6.6 Відображення вартості робіт
На верхньому рівні діаграми буде відображена загальна вартість робіт по

процесу:
Рис.6.7. Загальна вартість робіт
Далі необхідно згенерувати звіт Tools\Reports\Activity Cost Report і у вікні,

що відкриється необхідно задати параметри генерації (рис. 6.8).
69
Рис. 6.8. Задання параметрів генерації звіту Activity Cost Report
Фрагмент отриманого звіту приведено на рис. 6.9.
Рис.6.9. Фрагмент звіту
70
2. Використовуючи наведений приклад, здійснити вартісний аналіз
функціонування системи.
3. Описати всі роботи системи та визначити їх вартості.
4. Кінцевою метою роботи є розрахунок вартості всіх робіт та формування
кінцевого звіту
1. Інструменти для оцінювання моделі проекту
2. АВС методика оцінювання вартості проекту
3. UDP методика оцінювання вартості проекту
4. Особливості проведення вартісного аналізу в AllFusion Process Modeler
71
Метод дерева цілей
Мета роботи – ознайомитись з теоретичними відомостями та навчитись

застосовувати метод дерева цілей для вирішення інженерних задач.
Метод дерева цілей орієнтований на одержання повної і відносно стійкої
структури цілей, проблем, функцій, напрямків, тобто такої структури, яка мало
змінюватиметься протягом певного періоду часу при неминучих змінах, що
відбуваються в будь-якій системі, яка розвивається. Для досягнення цього при
побудові варіантів структури необхідно враховувати закономірності
цілеутворення і використовувати принципи і методики формування ієрархічних
структур цілей та функцій. Цілі випливають з об’єктивних потреб і мають
ієрархічний характер. При цьому, цілі верхнього рівня не можуть бути досягнуті,
поки не досягнуті цілі найближчого нижнього рівня. В міру переміщення вниз
рівнями ієрархії цілі конкретизуються. В процесі побудови та використання
дерева цілей необхідно прагнути чіткого і конкретного формулювання цілей,
забезпечити можливість кількісної чи якісної оцінки ступеня їх досягнення.
Крім того, цілі діяльності системи необхідно конкретизувати за часом і
виконавцями, тобто загальний остаточний результат, якого прагне система,
треба піддати декомпозиції на окремі задачі, що розв’язуватимуться в коротші
терміни. Крім того мета, якої прагне, наприклад, розробник при реалізації певної
ІС повинна конкретизуватись у вигляді окремих задач. При цьому необхідно,
визначити роль кожної при досягненні генеральної мети.
Структурування дає можливість деталізувати цілі і шляхи їхнього
досягнення, виявити існуючі між ними взаємозв’язки, забезпечити визначену
логіку розв’язання проблеми. Крім того, забезпечує можливості навіть при
проведенні суто якісного аналізу одержати нові ідеї, розкрити нові можливості
розв’язання досліджуваної проблеми на різних рівнях керування.
При цьому, конкретизація цілей зверху – вниз повинна зростати: чим
нижче рівень, тим в детальнішій формі визначається ціль, яку необхідно досягти.
Вимоги, які пред'являються до цілей в процесі побудови дерева цілей:
• цілі повинні бути досяжними, реальними (нереальна мета приводь до
демотивації працівників і втрати ними орієнтиру, що негативно
позначається на діяльності підприємства);
• цілі повинні бути гнучкими (цілі доцільно встановлювати так, щоб
залишалася можливість для їхнього коректування відповідно до змін
зовнішнього й внутрішнього середовища);
72
• цілі повинні бути вимірними (цілі необхідно формулювати так, щоб їх
можна було кількісно вимірювати або будь-яким способом об'єктивно
визначити, досягнуто мета чи ні);
• цілі повинні бути коректними (тобто ціль повинна давати чітке подання
про напрямок руху системи для її досягнення);
• цілі повинні бути сумісними (сумісність передбачає, що довгострокові цілі
відповідають основному завданню системи, а короткострокові – повинні
підпорядковуватись довгостроковим; при цьому важливо, щоб цілі не
суперечили одна іншій);
• цілі повинні бути прийнятними для основних суб'єктів взаємодії, які
визначають та оцінюють роботу системи, і, насамперед, для тих, які
використовують її функціональність.
Вершина «дерева цілей» відповідає основному виду діяльності, і її,
звичайно, називають, місією або генеральною метою і яка формує так званий 0
рівень. Подальша декомпозиція здійснюється для побудови «дерева цілей», щоб
зв'язати генеральну мету зі способами її досягнення.
Для перевірки повноти і внутрішньої несуперечливості дерева цілей
застосовуються наступні правила.
1. При просуванні згори донизу деревом цілей підціль-нащадок утворюється
шляхом відповіді на запитання «що потрібно зробити, щоб реалізувати
безпосередню ціль-предок попереднього рівня?»
2. При просуванні знизу догори ціль вищого рівня повинна відповідати на
запитання, для чого необхідна безпосередня підціль-нащадок.
3. При розгляді множини безпосередніх підцілей-нащадків, необхідних для
досягнення однієї цілі, необхідно уточнити, чи всі підцілі дійсно необхідні для
її досягнення.
4. При розгляді множини безпосередніх підцілей-нащадків, необхідних для
досягнення однієї цілі, слід уточнити, які ще безпосередні підцілі-нащадки
необхідні для досягнення мети.
Основне правило побудови "дерева цілей" - це "повнота редукції". Повнота
редукції - процес зведення складного явища, процесу або системи до більш
простих складових. Для реалізації цього правила використовують такий
системний підхід:
а) мета вищого рівня є орієнтиром, основою для розробки (декомпозиції) цілей
нижчого рівня;
б) цілі нижчого рівня є способами досягнення мети вищого рівня і мають бути
представлені так, щоб їхня сукупність зумовлювала досягнення початкової мети.
Незалежно від методу побудови «дерева цілей» процес формування системи
цілей має певну логіку, що трансформується в такі правила:
73
Правило 1. Формулювання цілей нижнього рівня за значенням повинне бути
більш конкретніше за формулювання цілей відповідно вищого рівня,
розкриваючи тим самим їх зміст.
Правило 2. Кожна ціль верхнього рівня ділиться не менш ніж на дві мети
нижнього рівня.
Правило 3. Не рекомендується опускатися на наступний рівень, поки на
розглянутому рівні не виконані умови:
• дана не тільки словесна, але й кількісна характеристика кожної цілі;
• критерії досягнення цілі розкриті в часі реалізації.
Формулювання цілей вважають завершеним, якщо починають
перераховувати не змістовні компоненти мети, а взаємозамінні шляхи її
реалізації, тобто переходять від аналізу цілей до аналізу заходів щодо їхнього
досягнення.
Зараз детальніше розглянемо приклад побудови дерева цілей для
інформаційно-консультаційної системи встановлення медичного діагнозу.
Головною ціллю (генеральною ціллю) є «Створення та розробка інформаційно-
консультаційної системи встановлення медичного діагнозу».
Рис. 7.1.. Дерево цілей розробка інформаційно-консультаційної системи

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

2. Визначити генеральну мету дерева цілей відповідно до індивідуального
завдання (обраної предметної області). Визначити цілі нащадки,
досягнення яких необхідне для реалізації генеральної мети.
3. Застосовуючи принцип повноти редукції, здійснити декомпозицію цілей
верхнього рівня та визначити критерії, які необхідно враховувати в процесі
досягнення генеральної мети.
4. Побудувати дерево цілей та здійснити його опис
1. Поняття дерева цілей та особливості використання
2. Етапи побудови дерева цілей
3. Вимоги, які висуваються до цілей в процесі побудови дерева цілей
4. Методи побудови дерева цілей
75
Методи експертних оцінок. Метод Дельфі
Мета роботи – ознайомитись з особливостями застосування методів експертних

оцінок та навчитись їх застосовувати для вирішення поставлених задач.
Особливий клас методів, що пов’язані безпосередньо з опитуванням
експертів, утворюють методи експертних оцінок (назва походить від специфіки
процедури отримання інформації від експертів, а саме при опитуваннях
експертів оцінки проставляються в балах і ранґах) і є одним з основних класів
методів науково-технічного прогнозування, який ґрунтується на припущенні, що
на основі думок експертів можна збудувати адекватну модель майбутнього
розвитку об'єкта прогнозування.
При застосуванні методу експертних оцінок проводиться опитування
спеціальної групи експертів (5–7 осіб) з метою визначення певних змінних
величин, необхідних для оцінки досліджуваного питання. Залучені експерти
можуть висловити свою думку щодо оптимальних способів вирішення завдання,
можливого залучення інвестицій, строків досягнення поставлених завдань,
критеріїв відбору оптимальних варіантів рішення тощо.
Необхідною умовою ефективного застосування методів експертних оцінок
є достатня обізнаність експерта з досліджуваної проблеми, високий рівень
ерудиції, здатність його давати чіткі вичерпні відповіді. Крім того, експерт не
повинен бути зацікавленим в тому чи іншому варіанті вирішення поставленої
перед ним задачі. При цьому, експерти підбираються за ознакою їх формального
професійного статусу – займаної посади, кваліфікаційних навичок, досвіду та
стажу роботи тощо. Такий підбір сприяє тому, що в число експертів потрапляють
високопрофесійні, з великим практичним досвідом у даній галузі спеціалісти.
Метод Дельфі – один із методів колективного експертного оцінювання,
який передбачає проведення експертного опитування серед групи спеціалістів у
кілька турів (частіше у 3–4 тури) для вибору найкращого із рішень. Метою
застосування методу Дельфі є удосконалення групового підходу до вирішення
завдання розробки прогнозу, оцінки за рахунок взаємної критики поглядів
окремих спеціалістів, висловлюваних без безпосередніх контактів між ними та
при збереженні анонімності думок чи аргументів на їх захист.
В розповсюдженому варіанті методу Дельфі:
• Під час першого туру для експертів формується мета експертизи та перелік
запитань у вигляді анкети, можливо з поясненням. Для складних систем
пояснення може бути представлене у вигляді концептуальної моделі системи та
характеру можливих відповідей. Оформлені результати-відповіді експертів на
анкети – опрацьовуються аналітичною групою. Аналітична група визначає
76
граничні точки зору – найвищі та найнижчі оцінки для кожної альтернативи,
середнє значення, верхні та нижні значення оцінок.
• На другому турі експерти отримують наступну інформацію: усереднені
оцінки альтернатив та обґрунтування (анонімні) граничних оцінок альтернатив,
– та корегують у відповідності до неї попередні оцінки. Скорегована інформація
опрацьовується аналітичною групою.
• Третій та четвертий тур за змістом не відрізняються від другого, при
переході від туру до туру покращується узгодженість оцінок.
Основні засоби підвищення об'єктивності результатів при застосуванні
Дельфі-методу - використання зворотного зв'язку, ознайомлення експертів з
результатами попереднього туру опитування та врахування цих результатів при
оцінці значимості думок експертів. У проведенні методу Дельфі обов'язково
повинні брати участь дві групи: перша – це незалежні експерти, які оцінюють
проблему (при виконанні лабораторної роботі дана роль на одногрупників
виконавця); друга група - це аналітики, які обробляють оцінки та приводять
результати до єдиного висновку (при виконанні лабораторної роботі дана роль
покладається на виконавця роботи).
При виконанні лабораторної роботи пропонується використання
СПРОЩЕНОЇ варіації методу, який включає такі етапи: підготовчий (включає
формування робочої групи експертів), основний (передбачає озвучування
проблеми, надсилання/отримування опитувальника) і підсумковий (оцінювання
результатів, процедура з опитувальником повторюється доти, доки всі учасники
не дійдуть єдиного висновку).
Приклад використання СПРОЩЕНОЇ ВАРІАЦІЇ МЕТОДУ ДЕЛЬФІ.
Можливі два підходи. При першому з них кожному члену групи даються 10 або
20 балів, які йому пропонується розподілити між розглянутими варіантами
відповідно до його експертного бачення. Після чого варіанти, які набрали
наперед зазначену кількість балів переходять в другий тур, серед яких за
найбільшою кількістю балів обирається найкращий варіант.
При другому підході кожен варіант оцінюється, наприклад, за 10 бальною
шкалою, також визначається коефіцієнт самооцінки експерта і за результатами
визначеного середнього балу по скорегованих оцінках визначається найкращий
варіант. В якості прикладу розглянемо задачу з вибору мови розроблення
системи розпізнавання образів на основі методу Віоли-Джонса.
77
Результат отриманий від експертів:
Експерт 1 Експерт 2 Експерт 3
компетентності
Варіант
Коефіцієнт
Оцінка
Оцінка
Оцінка
Python 9 1 9 0,8 10 0,7
C++ 8 1 10 0,8 8 0,7
Prolog 3 1 4 0,8 2 0,7
Delphi 2 1 5 0,8 1 0,7
Java 7 1 7 0,8 6 0,7
Далі необхідно визначити узгодженість думок експертів, для цього:

1) Для кожного варіанта рішення визначається середнє арифметичне з оцінок
всіх експертів. Так, для варіанта Python, Xaver = ( 9 + 9 +10)/ 3 = 9,33.
2) Розраховується середньоквадратичне відхилення за формулою:
∑(𝑋 − 𝑋𝑎𝑣𝑒𝑟 )2
𝑆=√
(𝑚 − 1)
де X – оцінки експертів, m – кількість експертів.
Для нашого прикладу маємо:
(9 − 9,33)2 + (9 − 9,33)2 + (10 − 9,33)2
𝑆=√ = 0,58
3−1
3) Підраховується коефіцієнт варіації за формулою:

K = S / Xaver = 0,58 / 9,33 = 0,062.
Думки експертів по кожному з варіантів вирішення вважаються

узгодженими, якщо коефіцієнт варіації не перевищує величини 0,25. Для
варіанту рішення Python в розглянутому прикладі отримуємо К = 0,062 <0,25.
Таким чином, думки експертів, представлені їх оцінками за спрощеним
варіантом вирішення Python, вважаються узгодженими. Подібна перевірка,
повинна проводитися для кожного варіанта (в нашому прикладі їх 4).
Далі визначається скорегована оцінка експерта, як добуток оцінки на
коефіцієнт компетентності та середній бал по скорегованих оцінках.
78
Експерт 1 Експерт 2 Експерт 3
Скорегована оцінка
Середній бал по
Оцінка
Оцінка
Оцінка
Варіант скорегованих
оцінках
Python 9 1 9 9 0,8 7,2 10 0,7 7 7,73

C++ 8 1 8 10 0,8 8 8 0,7 5,6 7,2
Prolog 3 1 3 4 0,8 3,2 2 0,7 1,4 2,53
Delphi 2 1 2 5 0,8 4,0 1 0,7 0,7 2,23
Java 7 1 7 7 0,8 2,8 6 0,7 4,2 4,66
З наведеного прикладу видно, що експерти кращим варіантом визнали
варіант Python, який набрав найбільшу суму балів (7,73).

2. Сформулювати в рамках досліджуваної предметної області – проблему.
3. Визначити групу експертів (не менше 5 осіб) та сформувати анкету з
використанням ресурсу Google Форми.
4. Запропонувати кожному експерту оцінити варіанти рішень з
використанням 10-бальної шкали та вказанням рівня його компетентності
в досліджуваній проблемі.
5. Розрахувати коефіцієнт узгодженості думок експертів. У разі, якщо думки
експертів не узгоджені, ознайомити їх з результатами оцінки варіантів
іншими експертами і запропонувати провести оцінку ще раз.
6. Визначити варіант, який набрав максимальну кількість балів.
7. Зробити висновки за підсумками виконаної роботи.
8. Всі кроки роботи повинні бути детально описані та проілюстровані.
1. Методи експертних оцінок, основні типи
2. В чому полягає основний зміст методу Дельфі?
3. Етапи проведення методу Дельфі
4. Як визначається узгодженість думок експертів?
79
СПИСОК РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ
1. Катренко А.В. Системний аналіз /Анатолій Васильович Катренко – Львів: Видавництво Новий
Світ 2000, 2013. - 396 с.
2. Згуровский М. З. Системный анализ: проблемы, методология, приложения : [монография] /
М. З. Згуровский, Н. Д. Панкратова ; НАН Украины, Мин-во образования и науки Украины,
Ин-т прикладного системного анализа – К.: Наукова думка, 2005. – 743с.
3. Анфилатов В.С. Системный анализ в управлении / в.с. Анфилатов, а. Л. Емельянов, а.а.
Кукушкин – М.: Финансы и статистика, 2002. - 368с.
4. Ржевський С.В. Дослідження операцій / С.В. Ржевський, В. М. Александрова. – К. :
Академвидав, 2006. – 558 с.
5. Мельник Л.Г. Экономика информации и информационные системы предприятия / Л.Г.
Мельник, С.Н. Ильяшенко, В.А. Касьяненко. – Сумы : ЛТД «Університетська книга», 2004. –
400 с.
6. Ілляшенко С. М. Управління інноваційним розвитком: проблеми, концепції, методи / С. М.
Ілляшенко. – Суми : ВТД «Університетська книга», 2003. – 278 с.
7. Шарапов О. Д. Системний аналіз / О. Д. Шарапов, Л. Л. Терехов, С. П. Сіднєв. – К. : Вища
школа, 1993. – 303 с.
8. Чорней Н. Б. Теорія систем і системний аналіз / Н. Б. Чорней, Р. К. Чорней. – К. : МАУП, 2005.
– 256 с.
80

++all Fussion - Labs - 2022 (8)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

++all Fussion - Labs - 2022 (8)

Uploaded by

Copyright:

Available Formats

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ УНІВЕРС ИТЕТ „ЛЬВІВСЬКА ПОЛІ ТЕХНІКА”

“МЕТОДОЛОГІЇ СИСТЕМНОГО АНАЛІЗУ”

Укладач: Басюк Т. М., к.т.н., доцент каф. ІСМ

ВИМОГИ ДО ОФОРМЛЕННЯ ЗВІТІВ ПРО ВИКОНАННЯ

Мета роботи – ознайомитись з основними принципами проектування

Рис.1.1. Створення нової моделі (а) та задання її властивостей (б)

Рис. 1.2. Головне вікно програми

Панель інструментів Model Toolbox

-IDEF3 Referent Tool Додавання на діаграму об’єкту посилання

Вкладка Activities дозволяє перейти на стандартні діаграми діяльності

Рис.1.3. Звіт по моделі

Стрілки (Arrows). Взаємодія процесів із зовнішнім світом описується у

Граничні стрілки ICOM (Input, Control, Output, Mechanism). Стрілки на

Рис. 1.4. Редактор словника стрілок

Рис. 1.6 Зв’язок по управлінню.

Рис. 1.7 Зворотний зв’язок по входу.

Рис. 1.8 Зворотний зв’язок по управлінню.

Створення звітів в AllFusion

Рис.1.11. Діалог Arrow Report

Створення звітів за допомогою Report Template Builder

Методика виконання роботи

Рис.1.13 Незаповнений блок

Рис.1.14. Побудована контексна діаграма

Рис.1.15. Попередній перегляд звіту

Мета роботи – ознайомитись з основними принципами проектування

Рис.2.1. Діалог Activity Box Count

Методика виконання роботи

Рис. 2.2. Діаграма декомпозиції

Далі необхідно створити нові внутрішні стрілки так, як показано на рис.

Рис.2.5. Стрілка Маркетингові матеріали

Рис.2.6. Результат виконання роботи

Табл.2.3. Стрілки діаграми декомпозиції А2

Рис. 2.7. Декомпозиція процесу Здійснити збирання комп‘ютерів

Мета роботи – ознайомитись з основними принципами проектування

Рис. 3.2. Процес в DFD

Рис. 3.3. Сховище даних в DFD

Рис.3.4. Вибір типу моделі

Рис. 3.6. Створення зовнішньої сутності у вікні External Reference

Рис.3.7. Розміщення зовнішніх сутностей на контекстній діаграмі

Рис.3.8. Налаштування параметрів інтерфейсної дуги

Рис.3.9. Контекстна діаграма проектованої системи

Інформація про особу

Призначити лікування та створити нагадування

Запит на уточнення діагнозу

Рис. 3.10. Збереження проектної версії DF-діаграми

Рис. 3.11. Вибір кількості процесів для декомпозиції

Рис. 3.13. Деталізована (декомпозиція 1 рівня) діаграма потоків даних

Рис. 3.14. Деталізована (декомпозиція 2 рівня) діаграма потоків даних для

Рис. 3.15. Деталізована (декомпозиція 2 рівня) діаграма потоків даних для

Рис. 3.16. Деталізована (декомпозиція 2 рівня) діаграма потоків даних для

Рис. 3.17. Деталізована (декомпозиція 2 рівня) діаграма потоків даних для

Порядок виконання роботи.

Мета роботи – ознайомитись з основними принципами проектування

Рис. 4.2. Перше діалогове вікно майстра Node Tree Wizard

Рис.4.3. Діаграма дерева вузлів

Рис.4.4. Результат виконання

Рис. 4.5. Діалогове вікно Add New FEO Diagram

Рис. 4.6. Діаграма FEO

Порядок виконання роботи.

Мета роботи – ознайомитись з основними принципами проектування

Зв'язки показують взаємовідношення між роботами. Всі зв'язки в IDEF3

Початок Початок Закінчення Закінчення