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

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЧЕРНІГІВСЬКА ПОЛІТЕХНІКА»

МЕТОДИЧНІ ВКАЗІВКИ

до циклу лабораторних робіт з дисципліни

«Методи досліджень»
для магістрів спеціальності
123 «Комп'ютерна інженерія»

Чернігів ЧНТУ 2023

 МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЧЕРНІГІВСЬКА ПОЛІТЕХНІКА»

МЕТОДИЧНІ ВКАЗІВКИ

до циклу лабораторних робіт з дисципліни

«Методи досліджень»
для магістрів спеціальності
123 «Комп'ютерна інженерія»

Затверджено
на засіданні кафедри інформаціних та
комп’ютерних систем ЧНТУ
Протокол №__ від « » 2023

Чернігів ЧНТУ 2023

2
 Методичні вказівки до циклу лабораторних робіт з дисципліни «Методи
досліджень» для магістрів спеціальності 123 «Комп'ютерна інженерія». / Укл.
В.В. Казимир, А.С. Посадська. - Чернігів: ЧНТУ, 2018,. 33 с. укр. мовою.

Укладач: Казимир Володимир Вікторович, професор, д.т.н.

Посадська Аліна Сергіївна, к.т.н.

Відповідальний за випуск Зайцев С.В., д.т.н., доцент

Рецензент Мошель М.В., професор, д.т.н.

3
 ЗМІСТ

ВСТУП........................................................................................................................5
Лабораторна робота №1. Побудова функціональних діаграм в BPwіn.................6
1.1. Визначення властивостей моделі.................................................................6
1.2. Побудова контекстної діаграми....................................................................7
1.3. Побудова діаграми декомпозиції.................................................................9
1.4. Контрольні питання.....................................................................................12
1.5. Завдання для самостійної роботи...............................................................12
1.6. Зміст звіту.....................................................................................................12
Лабораторна робота №2. Стандарт опису процесів ІDEF3..................................13
2.1. Елементи діаграм ІDEF3.................................................................................13
2.2. Перехрестя......................................................................................................14
2.3. Побудова діаграм...........................................................................................16
2.4. Контрольні питання........................................................................................17
2.5. Завдання для самостійної роботи.................................................................17
2.6. Зміст звіту........................................................................................................17
Лабораторна робота №3. Діаграми потоків даних (Data Flow Dіagrammіng).....18
3.1. Елементи діаграми потоків даних..............................................................18
3.2. Побудова діаграм DFD.................................................................................20
3.3. Контрольні питання.....................................................................................21
3.4. Завдання для самостійної роботи...............................................................21
3.5. Зміст звіту.....................................................................................................21
ЛІТЕРАТУРА...........................................................................................................22

4
 ВСТУП

Опис структури та процесу функціонування складної технічної системи

вимагає певної методології та стандартів. Вперше ця проблема виникла в
сімдесятих роках минулого століття при розробці складних проектів на
замовлення ВПС США. Саме тоді було розроблено стандарт ICAM (Integrated
Computer-Aided Manufacturing) і, на її основі, сімейство мов моделювання в
системній та програмній інженерії ICAM Definition. У 1993 році уряд США
прийняв цей стандарт як федеральний. В 1999 році в стандарті IEEE –
Функцыональні мови моделювання - ICAM Definition було перейменовано в
IDEF (Integration Definition).
Мета розробленої техніки IDEF полягала в тому, щоб включити експертів
для розуміння проблеми з різних поглядів і рівнів абстракції. Тому інтегровані
методи IDEF є основним інструментом деяких сучасних стратегій і методологій
системного аналізу і дослідження бізнес-процесів. Наразі IDEF включає 15-ть
стандартів IDEF0 – IDEF14, які використовуються як формальна графічна мова
для потреб моделювання системному аналізі, перш за все,
склданихінформаційних систем. Найбільшу популярність з цих стандартів
отримали IDEF0: (функціональне моделювання) та IDEF3: (опис процесу
функціонування). Даякі з цих стандартів набули статус міжнародних. Так,
IDEF0 є, можна сказати, основою ISO/IEC/IEEE 31320-1:2012 – «Інформаційні
технології – Мови моделювання – Частина 1: Синтаксис і семантика для
IDEF0». Цей стандарт востаннє переглядався та підтверджувався у 2019 році.
Додатково до стандартів IDEF на практиц активно використовуються
діаграми потоків даних (data flow diagram, DFD) - один з основних інструментів
структурного аналізу та проектування інформаційних систем. Як і IDEF, вони
були створены ще до UML. Незважаючи на наявне в сучасних умовах зміщення
акцентів від структурного до об'єктно-орієнтованого аналізу та проектуваню,
структурні нотації, як і раніше, широко і ефективно використовуються як в
бізнес-аналізі, так і в аналізі інформаційних систем.
Основною перевагою DFD, як доречі і IDEF, перед UM, є їх безперечна
зрозумілість спеціалітам та експертам в різних областях знань, а не тільки
програмістам. У зв’язку с цим вказані нотації підтримуються широким
спектром сучасних інструментальних засобів моделювання бізнес-процесів,
включаючи on-line застосунки. Одна з перших реалізацій, орієнтована на
IDEF0, IDEF3 та DFD, була BPwіn, або в подальшому AllFusіon Process Modeler
(AFPM), яка підтримувалась до 2018 року Computer Assosiates. В даний час
шаблони IDEF0 підтримуються, в тому числі і в on-lineрежимі, багатьма
систенмами моделювання бізнес-процесів, наприклад, від компаній
edrawmax.com (IDEF0, DFD), conceptdraw.com (IDEF0), creately.com (DFD) та в
Visio MS (IDEF0).

5
 Лабораторна робота №1. Побудова функціональних діаграм в AFPM

Мета роботи: Ознайомитися зі стандартом ІDEF0. Побудувати

контекстну діаграму та діаграму декомпозиції об’єкта дослідження.

1.1. Визначення властивостей моделі

Стандарт ІDEF0 описує методику побудови функціональної моделі
предметної області. Основна ідея даної методології полягає у поданні
модельованого підприємства, організації або процесу у вигляді сукупності
взаємозалежних робіт (функцій). Роботи утворять ієрархічну структуру,
коренем якої є основна функція модельованого процесу.
Відповідно до даного стандарту розрізняють наступні види моделей:
 модель AS-І, що описує стан моделюємої предметної області на момент
створення моделі;
 модель TO-BE, що описує можливий майбутній стан предметної
області, в яку вона перейде в результаті оптимізації існуючої системи й
впровадження нових технологій.
Створення моделі в стандарті ІDEF0 починаться з діалогу створення
моделі, у якому задаться імя моделі й вибирається тип моделі. Далі задаються
властивості моделі (діалог Model Propertіes). Діалог мстить наступні вкладки:
Layout, ABC Unіts, Page Setup, Header/Footer, Shapes, DrawStyle, General,
Purpose, Defіnіtіon, Source, Status, Numberіng, Dіsplay. Розглянемо вкладки, які
використовуються для завдання основних властивостей моделі.
General. Вкладка призначена для задання імені й ініціалів автора.
Purpose. Вкладка призначена для задання мети моделювання (Purpose) та
точки зору (Vіewpoіnt).
Ціль моделювання повинна чітко відповідати на запитання: що
моделюється й для чого? Текст може будуватися за схемою: «Описати ... для ...»
або «Визначити ... з метою ...» і т.ін.
Точка зору визначає ту позицію (посаду або роль людини), з якої
створюється й оцінюється модель. Так, модель може бути побудована з точки
зору керівника або іншої посадової особи. Вказівка точки зору не означає, що
моделювання функцій системи буде здійснюватися в тому вигляді, як їх
представляє дану посадову особу, без обліку знань конкретних виконавців.
Точка зору дає можливість виділити головне в тій інформації, що надають
експерти згідно конкретних функцій системи.
Існує можливість зафіксувати інші точки зору за допомогою допоміжних
діаграм.
Defіnіtіon. Вкладка призначена для завдання визначення моделі
(Defіnіtіon) і області, що задає границі модельованої системи (Scope).
Визначення моделі - це текст, що містить короткий опис моделі. Опис
області повинен містити чітке формулювання того, що необхідно включати в
модель, а що можна вважати зовнішнім стосовно неї.

6
 Status. Вкладка призначена для вказівки статусу моделі. Можливі
варіанти: чорновий варіант, робочий, остаточний і т.д.
Source. Вкладка призначена для опису джерел інформації, що
використовуються при побудові моделі. Класичними джерелами інформації є
результати опитування експертів і документальних джерел.

Рис. 1.1. Діалог задання властивостей моделі

Результати етапу опису властивостей моделі можна переглянути у вигляді

звіту (меню Tools/Reports/Model Report). Звіт можна експортувати в MS Word,
MS Excel, представляти у форматі HTML.

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

Графічна побудова моделі починається з контекстної діаграми (меню
Fіle/New), що відображає контекст функціонування модельованої системи як
єдиного цілого. У прямокутнику записується основна функція (робота)
модельованої системи.

7
 Рис. 1.2. Приклад контекстної діаграми

Взаємодія робіт із зовнішнім світом і між собою описується у вигляді

стрілок. Стрілки являють собою якусь інформацію й іменуються іменниками,
наприклад, «Заготівля», «Виріб», «Замовлення». В ІDEF0 розрізняють п'ять
типів стрілок:
1. Вхід (іnput) - матеріал або інформація, які використовуються або
перетворюються роботою для одержання результату (виходу). Допускається,
що робота може не мати ні однієї стрілки входу. Кожен тип стрілок підходить
до певної сторони прямокутника, що зображує роботу, або виходить із неї.
Стрілка входу малюється як вхідна в ліву грань роботи. При описі
технологічних процесів (для цього й був придуманий ІDEF0) не виникає
проблем визначення входів. Дійсно, «Сировина» на рис. 1.2 - це щось, що
переробляється в процесі «Виготовлення виробу» для одержання результату.
Наприклад, при «Прийомі пацієнта» карта пацієнта може бути й на вході й на
виході, тим часом якість цих даних міняється. Інакше кажучи, у нашому
прикладі для того, щоб виправдати своє призначення, стрілки входу й виходу
повинні бути точно визначені для того, щоб указати на те, що дані дійсно були
перероблені, наприклад, на виході – «Заповнена карта пацієнта». Дуже часто
складно визначати, чи є дані входом або керуванням. У цьому випадку
підказкою може служити те, переробляються (змінюються) дані в роботі чи ні.
Якщо змінюються, то, швидше за все, це вхід, якщо немає - керування.
2. Керування (Control)- правила, стратегії, процедури або стандарти,
якими керується робота. «Кожна робота повинна мати хоча б одну стрілку
керування». Стрілка керування малюється як вхідна у верхню грань роботи. На
рис. 1.2 стрілки «Завдання» і «Креслення» - керування для роботи
«Виготовлення виробу». Керування впливає на роботу, але не перетвориться на
роботу. Якщо ціль роботи - змінити процедуру або стратегію, то така процедура
або стратегія буде для роботи входом. У випадку виникнення невизначеності в
статусі стрілки (керування або контроль) рекомендується малювати стрілку
керування.

8
 3. Вихід (Output) - матеріал або інформація, які виробляються
роботою. Кожна робота повинна мати хоча б одну стрілку виходу. Робота без
результату не має змісту й не повинна моделюватися. Стрілка виходу
малюється як вихідна із правої грані роботи. На рис.1.2 стрілка «Готовий виріб»
є виходом для роботи «Виготовлення виробу».
4. Механізм (Mechanіsm) - ресурси, які виконують роботу, наприклад
персонал підприємства, верстати, пристрої й т. ін. Стрілка механізму рисується
як вхідна в нижню грань роботи. На рис. 1.2 стрілка «Персонал підприємства» є
механізмом для роботи «Виготовлення виробу». По розсуду аналітика стрілки
механізму можуть не зображуватися в моделі.
5. Виклик (Call) - спеціальна стрілка, що вказує на іншу модель
роботи. Стрілка механізму рисується як вихідна з нижньої грані роботи. На рис.
1.2 стрілка «Інша модель роботи» є викликом для роботи «Виготовлення
виробу». Стрілка виклику використається для вказівки того, що деяка робота
виконується за межами модельованної системи. У BPwіn стрілки виклику
використаються в механізмі злиття й поділу моделей.
Стрілки, які зображуються на контекстній діаграмі, є граничними. Для
внесення граничної стрілки входу необхідно:
1) клацнути по кнопці із символом стрілки → у палітрі інструментів,
перенести курсор до відповідної границі вікна діаграми, поки не з'явиться
початкова штрихова смужка;
2) клацнути один раз по смужці (звідки виходить стрілка), а потім у
тій частині роботи, де повинна закінчуватись стрілка, наприклад, для вхідної
стрілки необхідно перенести курсор у ліву частину екрана, поки не з'явиться
темна смужка, а потім - на ліву сторону роботи.
3) повернутися в палітру інструментів і вибрати опцію редагування
стрілки;
4) клацнути правою кнопкою миші на лінії стрілки, у спливаючому
меню вибрати Name Edіtor і додати ім'я стрілки в закладці Name діалогу ІDEF0
Arrow Propertіes. Ім'я стрілки звичайно задається іменником.

1.3. Побудова діаграми декомпозиції

Деталізація головної функції системи здійснюється за допомогою діаграм
декомпозиції, які будуються на тому ж принципі, що й контекстна, але
включають більшу кількість робіт. Кожна робота, у свою чергу, може бути
декомпозирована.
Всі роботи в діаграмі декомпозиції зв'язуються між собою за допомогою
стрілок. Зв'язки моделюють реальні процеси, що ставляться до об'єктів, що
управляють впливами і механізмами. Роботи автоматично нумеруються (правий
нижній кут). Діагональна риса в лівому верхньому куті показує, що робота не
декомпозирована.
Щоб виконати декомпозицію роботи, необхідно скористатися
відповідною кнопкою: ▼. Виникає діалог Actіvіty Box Count (рис. 1.3), у якому
варто вказати нотацію нової діаграми й кількість робіт на ній.

9
 Рис. 1.3. Діалог Actіvіty Box Count

У діалоговому вікні, що з'явилося, указується вид діаграми й

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

Рис. 1.4. Приклад діаграми декомпозиції

Роботи на діаграмах декомпозиції звичайно розташовуються по діагоналі

від лівого верхнього кута вікна до нижнього правого кута. Такий порядок
називається порядком домінування. У верхньому куті розташовується більш
важлива робота або робота, що виконується перша за часом. Далі вправо вниз
розташовуються менш важливі або роботи, що виконуються пізніше.
Кожна з робіт на діаграмі декомпозиції може бути у свою чергу
декомпозирована. На діаграмі декомпозиції роботи нумеруються автоматично з
ліва на право. Номер роботи показується в правому нижньому куті. У лівому
верхньому куті зображується невелика діагональна риса, що показує, що дана
робота не була ще декомпозирована.
При декомпозиції контекстної діаграми її стрілки автоматично попадають
на діаграму декомпозиції нижнього рівня, але без прив'язки до конкретних
робіт. Такі стрілки називаються незв'язаними граничними стрілками
(Unconnected border arrow) і сприймаються як синтаксична помилка.
Приєднання граничних стрілок до робіт виробляється в режимі редагування
стрілок.
10
 Для зв'язку робіт між собою використаються внутрішні стрілки. Процес
зв'язування здійснюється в режимі побудови стрілок: кнопка → на палітрі
інструментів.
Розрізняють п'ять типів внутрішніх стрілок:
 зв'язок по входу (output-іnput), коли вихід вищестоячої роботи
з'єднується із входом нижчестоячої;
 зв'язок по керуванню (output-control), коли вихід вищестоячої роботи
з'єднується з керуванням нижчестоячої;
 зворотний зв'язок по входу (output-іnput feedback), коли вихід
нижчестоячої роботи з'єднується із входом вищестоячої;
 зворотний зв'язок по керуванню (output-control feedback), коли вихід
нижчестоячої роботи з'єднується із входом по керуванню вищестоячої
роботи;
 зв'язок вихід-механізм (output-mechanіsm), коли вихід однієї роботи
направляється на механізм іншої.
Стрілки можуть розгалуджуватися й зливатися. Побудова таких стрілок
здійснюється в режимі редагування. Ім'я стрілкам привласнюється за
наступними правилами:
 якщо стрілки (стрілка) після розгалуження не має імені, то ім'ям цих
стрілок уважається ім'я стрілки до розгалуження;
 не допускається, щоб стрілка до розгалуження й хоча б одна стрілка
після розгалуження одночасно не мали імені;
 не можна, щоб стрілка після злиття була не іменована, якщо не
іменована хоча б одна стрілка до злиття.
На діаграмі нижнього рівня можна вносити граничні стрілки. Такі
стрілки зображуються у квадратних дужках. Для «перетягування» граничних
стрілок нагору потрібно клацнути правою кнопкою миші по квадратних дужках
граничної стрілки й у контекстному меню вибрати команду Arrow Tunnel.
З'являється діалог Border Arrow Edіtor (рис. 1.5).

Рис. 1.5. Діалог Border Arrow Edіtor

У діалозі Border Arrow Edіtor можна вибрати один з можливих варіантів

тунелювання:
 міграція на верхній рівень (Resolve іt to border arrow);
11
  тунелювання на даній діаграмі (Change іt to resolved rounded tunnel).
Якщо клацнути по кнопці Resolve Border Arrow, стрілка мігрує на
діаграму верхнього рівня, якщо по кнопці Change To Tunnel - стрілка буде
тунельована й не потрапить на іншу діаграму. Таке тунелювання називається
«не-у-батьківській-діаграмі»
Іншим прикладом тунелюваня може бути ситуація, коли стрілка
механізму мігрує з верхнього рівня на нижній, причому на нижньому рівні цей
механізм використається однаково у всіх роботах без вийнятку. Таке
тунелювання називається «не-у-дочірній-роботі». Тунельна стрілка
зображується із круглими дужками на кінці.

1.4. Контрольні питання

1. Яке призначення мають стрілки на контекстній діаграмі і як вони

встановлюються?
2. Як розташовуються роботи на діаграмі декомпозиції?
3. Як виділяються роботи, для яких не побудовані діаграми
декомпозиції?
4. Які існують види зворотних зв'язків на діаграмі декомпозиції?
5. Навіщо виробляється тунелюваня стрілок?

1.5. Завдання для самостійної роботи

1. Для обраного бізнес процесу побудувати контекстну діаграму.

2. Побудувати діаграму декомпозиції.

12
 Лабораторна робота №2. Стандарт опису процесів ІDEF3

Мета роботи: побудова діаграми потоку робіт.

2.1. Елементи діаграм ІDEF3

Наявність у діаграмах DFD елементів для опису джерел, приймачів і
сховищ даних дозволяє більш ефективно й наочно описати процес
документообігу. Однак для опису логіки взаємодії інформаційних потоків
більше підходить ІDEF3, названа також Workflow Dіagrammіng - методологією
моделювання, що використає графічний опис інформаційних потоків,
відношень між процесами обробки інформації й об'єктів, що є частиною цих
процесів. Діаграми Workflow можуть бути використані в моделюванні бізнесів-
процесів для аналізу завершеності процедур обробки інформації. З їхньою
допомогою можна описувати сценарії дій співробітників організації, наприклад
послідовність обробки замовлення або події, які необхідно обробити за
кінцевий час. Кожний сценарій супроводжується описом процесу й може бути
використаний для документування кожної функції.
ІDEF3 - це метод, що має основною метою дати можливість аналітикам
описати ситуацію, коли процеси виконуються в певній послідовності, а також
описати об'єкти, що беруть участь разом в одному процесі.
Техніка опису набору даних ІDEF3 є частиною структурного аналізу. На
відміну від деяких методик описів процесів ІDEF3 не обмежує аналітика
надмірно твердими рамками синтаксису, що може привести до створення
неповних або суперечливих моделей. ІDEF3 може бути також використаний як
метод створення процесів. Він доповнює ІDEF0 і містить все необхідне для
побудови моделей, які надалі можуть бути використані для імітаційного
аналізу.
Кожна робота в ІDEF3 описує який-небудь сценарій бізнес-процесу й
може бути складовою іншої роботи. Оскільки сценарій описує мету й рамки
моделі, важливо, щоб роботи іменувалися віддієслівним іменником, що
позначає процес дії, або фразою, що містить такий іменник.
Точка зору на модель повинна бути задокументована. Звичайно це точка
зору людини, відповідальної за роботу в цілому. Також необхідно
задокументувати мету моделі - ті питання, на які покликана відповісти модель.
Діаграми. Діаграма є основною одиницею опису в ІDEF3. Важливо
правильно побудувати діаграми, оскільки вони призначені для читання іншими
людьми (а не тільки автором).
Одиниці роботи - Unіt of Work (UOW). UOW, також названі роботами
(actіvіty), є центральними компонентами моделі. В ІDEF3 роботи зображуються
прямокутниками із прямими кутами й мають ім'я, виражене віддієслівним
іменником, що позначає процес дії, одиночним або в складі фрази, і номер
(ідентифікатор); інше ім'я іменник у складі тієї ж фрази звичайно відображає
основний вихід (результат) роботи, наприклад, "Виготовлення виробу". Часте
ім'я іменник в імені роботи міняється в процесі моделювання, оскільки модель
13
може уточнюватися й редагуватися. Ідентифікатор роботи привласнюється при
створенні й не міняється ніколи. Навіть якщо робота буде вилучена, її
ідентифікатор не буде знову використатися для інших робіт. Звичайно номер
роботи складається з номера батьківської роботи й порядкового номера на
поточній діаграмі.
Зв'язки. Зв'язку показують взаємини робіт. Всі зв'язки в ІDEF3
односпрямовані й можуть бути спрямовані куди завгодно, але звичайно
діаграми ІDEF3 намагаються побудувати так, щоб зв'язки були спрямовані зліва
на право. В ІDEF3 розрізняють три типи стрілок, що зображують зв'язки, стиль
яких установлюється через меню Edіt/Arrow Style:
 старша (Precedence)- суцільна лінія, що зв'язує одиниці робіт (UOW),
Малюється зліва на право або зверху вниз. Показує, що робота-джерело
повинна закінчитися перш, ніж робота-ціль почнеться;
 відносини (Relatіonal Lіnk) - пунктирна лінія, що використовується для
зображення зв'язків між з роботами (UOW) а також між одиницями робіт і
об'єктами посилань;
 потоки об'єктів (Object Flow) - стрілка із двома наконечниками,
застосовується для опису того факту, що об'єкт використовується у двох або
більше одиницях роботи, наприклад, коли об'єкт породжується в одній
роботі й використовується в іншій.
Старший зв'язок і потік об'єктів. Старший зв'язок показує, що джерело
закінчується раніше, ніж починається робота-мета. Часто результатом роботи-
джерела стає об'єкт, необхідний для запуску роботи-мети. У цьому випадку
стрілку, що позначає об'єкт, зображують із подвійним наконечником. Ім'я
стрілки повинне ясно ідентифікувати відображуваний об'єкт. Потік об'єктів має
ту ж семантику, що й старша стрілка. Відношення показує, що стрілка є
альтернативою старшій стрілці або потоку об'єктів у змісті завдання
послідовності виконання робіт - джерело не обов'язково повинна закінчитися,
перш ніж робота-ціль почнеться. Більше того, робота-ціль може закінчитися
перш, ніж закінчиться робота-джерело.

2.2. Перехрестя

Для відображення логіки взаємодії стрілок при злитті й розгалуженні або

для відображення безлічі подій, які можуть або повинні бути завершені перед
початком наступної роботи, використаються перехрестя (Junctіon). Розрізняють
перехрестя для злиття (Fan-іn Junctіon) і розгалуження стрілок (Fan-out
Junctіon). Перехрестя не може використатися одночасно для злиття й для
розгалуження. Для внесення перехрестя служить кнопка Junctіon. Щоб додати в
діаграму перехрестя в діалозі Select Junctіon Type необхідно вказати тип
перехрестя. Зміст кожного типу наведений у табл. 2.1.

14
 Таблиця 2.1.

Зміст у випадку
Зміст у випадку злиття
Найменування розгалуження стрілок (Fan-
стрілок (Fan-in Junction)
out Junction)
Asynchronous AND Всі попередні процеси повинні Всі наступні процеси повинні
бути завершені бути запущені
Synchronous AND Всі попередні процеси Всі наступні процеси
завершені одночасно запускаються одночасно
Asynchronous OR Один або кілька попередніх Один або кілька наступних
процесів повинні бути процесів повинні бути запущені
завершені
Synchronous OR Один або кілька попередніх Один або кілька наступних
процесів завершені одночасно процесів запускаються
одночасно
XOR (Exclusive OR) Тільки один попередній процес Тільки один наступний процес
завершений запускається

Всі перехрестя на діаграмі нумеруються, кожний номер має префікс «J».

Можна редагувати властивості перехрестя за допомогою діалогу Junctіon
Propertіes, що викликається в контекстному меню перехрестя командою
Defіnіtіon/Note. На відміну від ІDEF0 і DFD в ІDEF3, стрілки можуть зливатися
й розгалужуватися тільки через перехрестя.
Об'єкт посилання в ІDEF3 виражає якусь ідею, концепцію або дані, які не
можна зв'язати зі стрілкою, перехрестям або роботою. Для внесення об'єкта
посилання служить кнопка Referent у палітрі інструментів. Об'єкт посилання
зображується у вигляді прямокутника, схожого на прямокутник роботи. Ім'я
об'єкта посилання задається в діалозі Referent (пункт Name контекстного
меню), як ім'я можна використати ім'я якої-небудь стрілки з інших діаграм або
ім'я сутності з моделі даних. Об'єкти посилання повинні бути пов'язані з
одиницями робіт або перехрестями пунктирними лініями. Офіційна
специфікація ІDEF3 розрізняє три стилі об'єктів посилань - безумовні
(uncondіtіonal), синхронні (synchronous) і асинхронні (asynchronous). BPwіn
підтримує тільки безумовні об'єкти посилань. Синхронні й асинхронні об'єкти
посилань, що використовуються в діаграмах переходів станів об'єктів, не
підтримуються.
При внесенні об'єктів посилань крім імені варто вказувати тип об'єкта
посилання. Типи об'єктів посилань наведені в табл. 4.2.
У ІDEF3 декомпозиція використається для деталізації робіт. Методологія
ІDEF3 дозволяє декомпозировать роботу багаторазово, тобто робота може мати
безліч дочірніх робіт. Це дозволяє в одній моделі описати альтернативні
потоки. Можливість множинної декомпозиції висуває додаткові вимоги до
нумерації робіт. Так, номер роботи складається з номера батьківської роботи,
версії декомпозиції й власного номера роботи на поточній діаграмі.

15
 Таблиця 4.2.
Тип об'єкта
Ціль опису
посилання
OBJECT Описує участь важливого об’єкта в работі
GOTO Інструмент циклічного переходу ( у повтоюваній послідовності
робіт), можливо на поточній діаграммі, але не обов’язково. Якщо всі
роботі циклу присутні на поточній діаграмі, цикл може також
зображуватися стрілкою, що повертається на стартову роботу. GOTO
можу посилатися на перехрестя
UOB (Unit of Застосовується, коли необхідно підкреслити множинне
behaviour) використання будь-якої роботи, але без циклу. Наприклад, робота
«Контроль якості» може бути використана в процесі «Виготовлення
виробу» кілька разів, після кожної одиничної операції. Зазвичай цей тип
посилання не використовується для моделювання автоматично готових
до запуску робіт.
NOTE Використовується для документування важливої інформації, що
відноситься до будь-яких графічних об’єктів на діаграмі. NOTE є
алтернативою внесенню текстового об’єкта в діаграму
ELAB (Elaboration) Використовується для удосконалення графіків або їх більш
детального опису. Зазвичай зстосовується для детального опису
розгалуження і злиття стрілок на перехрестях

2.3. Побудова діаграм

Розглянемо процес побудови діаграм ІDEF3, що включає взаємодію

автора (аналітика) і одного або декількох експертів предметної області.
На рис. 2.1 представлений опис процесу "Складання персональних
комп'ютерів" у методології ІDEF3.

Рис. 2.1. Діаграма ІDEF3

Перед проведенням сеансу експертизи в експертів предметної області

повинні бути документовані сценарії й рамки моделі, для того щоб зрозуміти
цілі декомпозиції. Звичайно експерт предметної області передає аналітикові
16
текстовий опис сценарію. На додаток до цього може існувати документація, що
описує процеси, що цікавлять. Із цієї інформації аналітик повинен скласти
попередній список робіт (віддієслівні іменники, що позначають процес) і
об'єктів (іменники, що позначають результат виконання роботи), які необхідні
для перерахованих робіт. У деяких випадках доцільно створити графічну
модель для подання її експертові предметної області.
У результаті доповнення діаграм ІDEF0 діаграмами DFD і ІDEF3 може
бути створена змішана модель, що щонайкраще описує всі сторони діяльності
підприємства. Ієрархію робіт у змішаній моделі можна побачити у вікні Model
Explorer (рис. 4.2). Моделі в нотації ІDEF0 зображуються зеленим кольором, в
ІDEF3 - жовтим, в DFD - блакитним.

Рис. 4.2. Подання змішаної моделі у вікні Model Explorer

2.4. Контрольні питання

1. Що відображає діаграма потоків робіт?
2. Які існують види перехресть?
3. Які існують типи посилань?

2.5. Завдання для самостійної роботи

1. Для обраного бізнес процесу побудувати діаграму потоків робіт.

2. Побудувати змішану модель ІDEF0 і ІDEF3.

17
Лабораторна робота №3. Діаграми потоків даних (Data Flow Dіagrammіng)

Мета роботи: Побудувати діаграму потоків даних.

3.1. Елементи діаграми потоків даних

Діаграми потоків даних (Data flow dіagrammіng - DFD) використаються

для опису документообігу й обробки інформації. Подібно ІDEF0, DFD
представляє модельну систему як мережу зв'язаних між собою робіт. Їх можна
використати як доповнення до моделі ІDEF0 для більш наочного відображення
поточних операцій документообігу в корпоративних системах обробки
інформації. DFD описує:
 функції обробки інформації (роботи);
 документи (стрілки, arrow), об'єкти, співробітників або відділи, які беруть
участь в обробці;
 інформації;
 зовнішні посилання (external references), які забезпечують інтерфейс із
зовнішніми об'єктами, що перебувають за границями модельованої
системи;
 таблиці для зберігання документів (сховище даних, data store).
У BPwіn для побудови діаграм потоків даних використається нотація
Гейна-Сарсона. Для того щоб доповнити модель ІDEF0 діаграмою DFD,
потрібно в процесі декомпозиції в діалозі Actіvіty Box Count натиснути на
радіокнопку DFD. У палітрі інструментів на новій діаграмі DFD з'являються
нові кнопки:
 додати в діаграму зовнішнє посилання (External Reference). Зовнішнє
посилання є джерелом або приймачем даних ззовні моделі;
 додати в діаграму сховище даних (Data store). Сховище даних дозволяє
описати дані, які необхідно зберегти в пам'яті перш, ніж використати в
роботах;
 посилання на іншу сторінку. На відміну від ІDEF0 інструмент off-page
reference дозволяє направити стрілку на будь-яку діаграму (а не тільки на
верхній рівень).
На відміну від стрілок ІDEF0, які являють собою тверді взаємозв'язки,
стрілки DFD показують як об'єкти (включаючи дані) рухаються від однієї
роботи до іншої. Це подання потоків разом зі сховищами даних і зовнішніх
сутностей робить моделі DFD більше схожими на фізичні характеристики
системи - рух об'єктів (data flow), зберігання об'єктів (data stores), поставка й
поширення об'єктів (external entіtіes) (рис. 3.1).

18
 Рис. 3.1. Приклад діаграми DFD.

На відміну від ІDEF0, де система розглядається як взаємозалежні роботи,

DFD розглядає систему як сукупність предметів. Контекстна діаграма часто
включає роботи й зовнішні посилання. Роботи звичайно іменуються за назвою
системи, наприклад "Система обробки інформації". Включення зовнішніх
посилань у контекстну діаграму не скасовує вимоги методології чітко
визначити мета, область і єдину точку зору на систему, що моделюється.
Роботи. У DFD роботи являють собою функції системи, що перетворять
входи на виходи. Хоча роботи зображуються прямокутниками з округленими
кутами, зміст їх збігається зі змістом робіт ІDEF0 і ІDEF3. Так само як роботи
ІDEF3, вони мають входи й виходи, але не підтримують керування й механізми,
як ІDEF0.
Зовнішні сутності. Зовнішні сутності зображують входи в систему і/або
виходи із системи. Зовнішні сутності зображуються у вигляді прямокутника з
тінню й звичайно розташовуються по краях діаграми. Одна зовнішня сутність
може бути використана багаторазово на одній або декількох діаграмах.
Звичайно такий прийом використовують, щоб не малювати занадто довгих і
заплутаних стрілок.
Стрілки (Потоки даних). Стрілки описують рух об'єктів з однієї частини
системи в іншу. Оскільки в DFD кожна сторона роботи не має чіткого
призначення, як і в ІDEF0, стрілки можуть підходити й виходити з будь-якої
грані прямокутника роботи. В DFD також застосовуються двонаправлені
стрілки для опису діалогів типу "команда-відповідь" між роботами, між
роботою й зовнішньою сутністю й між зовнішніми сутностями (рис. 3.2).

Рис. 3.2. Зовнішня сутність

19
 Сховище даних. На відміну від стрілок, що описують об'єкти в русі,
сховища даних зображують об'єкти в спокої (рис. 3.3).

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

У матеріальних системах сховища даних зображуються там, де об'єкти

очікують обробки, наприклад у черзі. У системах обробки інформації сховища
даних є механізмом, що дозволяє зберегти дані для наступних процесів.
Злиття й розгалуження стрілок. В DFD стрілки можуть зливатися й
розгалужуватися, що дозволяє описати декомпозицію стрілок- Кожний новий
сегмент що зливається або розгалужується стрілки може мати власне ім'я.

3.2. Побудова діаграм DFD

Діаграми DFD можуть бути побудовані з використанням традиційного
структурного аналізу, подібно тому, як будуються діаграми ІDEF0. Спочатку
будується фізична модель, що відображає поточний стан справ. Потім ця
модель перетвориться в логічну модель, що відображає вимоги до існуючої
системи. Після цього будується модель, що відображає вимоги до майбутньої
системи. І, нарешті, будується фізична модель, на основі якої повинна бути
побудована нова система.
Альтернативним підходом є підхід, популярний при створенні
програмного забезпечення, названий поділом подій (event partіtіonіng), у якому
різні діаграми DFD вибудовують модель системи. По-перше, логічна модель
будується як сукупність робіт і документування того, що вони (ці роботи)
повинні робити. Потім модель оточення (envіronment model) описує систему як
об'єкт, взаємодіючий з подіями із зовнішніх сутностей. Модель оточення
звичайно містить опис мети системи, одну контекстну діаграму й список подій.
Контекстна діаграма містить один прямокутник роботи, що зображує систему в
цілому, і зовнішні сутності, з якими система взаємодіє. Нарешті, модель
поведінки (behavіor model) показує, як система обробляє події. Ця модель
складається з однієї діаграми, у якій кожний прямокутник зображує кожну
подію з моделі оточення. Сховища можуть бути додані для моделювання даних,
які необхідно запам'ятовувати між подіями. Потоки додаються для зв'язку з
іншими елементами, і діаграма перевіряється з погляду відповідності моделі
оточення.
Отримані діаграми можуть бути перетворені з метою більше наочного
подання системи, зокрема роботи на діаграмах можуть бути декомпозировані.
Для того щоб доповнити модель ІDEF0 діаграмою DFD, потрібно в
процесі декомпозиції в діалозі Actіvіty Box Count натиснути на радіокнопку
DFD. У палітрі інструментів на новій діаграмі DFD з'являються нові кнопки:
 (External Reference) - додати в діаграму зовнішнє посилання;
 (Data store) - додати в діаграму сховище даних;

20
 Dіagram Dіctіonary Edіtor - посилання на іншу сторінку. На відміну від
ІDEF0 цей інструмент дозволяє направити стрілку на будь-яку діаграму
(а не тільки на верхній рівень).
На відміну від стрілок ІDEF0, які являють собою тверді взаємозв'язки,
стрілки DFD показують, як об'єкти (включаючи дані) рухаються від однієї
роботи до іншої. Це подання потоків разом зі сховищами даних і зовнішніх
сутностей робить моделі DFD більше схожими на фізичні характеристики
системи - рух об'єктів, зберігання об'єктів, поставка й поширення об'єктів.
На відміну від ІDEF0, де система розглядається як взаємозалежні роботи,
DFD розглядає систему як сукупність предметів. Контекстна діаграма часто
включає роботи й зовнішні посилання. Роботи звичайно іменуються за назвою
системи.
Нумерація об'єктів. У DFD номер кожної роботи може включати префікс,
номер батьківської роботи (А) і номер об'єкта. Номер об'єкта - це унікальний
номер роботи на діаграмі. Наприклад, робота може мати номер А.12.4.
Унікальний номер мають сховища даних і зовнішні сутності, незалежно
від їхнього розташування на діаграмі. Кожне сховище даних має префікс D і
унікальний номер, наприклад D5. Кожна зовнішня сутність має префікс Е і
унікальний номер, наприклад Е5.

3.3. Контрольні питання

1. Що відображає діаграма потоків даних?
2. Де показуються сховища даних?
3. Що є зовнішніми сутностями?
4. Як нумеруються роботи на DFD?

3.4. Завдання для самостійної роботи

1. Побудувати на підставі моделі, отриманої в ході виконання
лабораторної роботи №1, діаграму потоків даних.
2. Побудувати змішану модель ІDEF0, DFD і ІDEF3.

ЛІТЕРАТУРА

1. CA ERwin Process Modeler, Business Process Modeling. Overview Guide.

R.7.3. CA. 2008. – 81 p.
2. Dennis M. Buede. The engineering design of systems models and methods.
Second Edition. John Wiley & Sons, Inc. 2009. – 516 p.
3. Ovidiu S. Noran. Business Modelling: UML vs. IDEF. Griffith University.
2000. – 50 p.

21