Лекція 2.1 Функціональне моделювання. Методології функціонального моделювання

1. Особливості моделювання бізнес-процесів згідно стандарту IDEF0

1.1. Правила побудови моделей.

1.2. Принципи моделювання в IDEF0

1.3. Основні елементи і поняття IDEF0

1.1. Правила побудови моделей.

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

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

Ці блоки представляють основні підфункції (підмодулі) єдиного вихідного модуля.

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

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

1.2. Принципи моделювання в IDEF0

У IDEF0 реалізовані три базових принципи моделювання процесів:

принцип функціональної декомпозиції;

принцип обмеження складності;

принцип контексту.

• Принцип функціональної декомпозиції являє собою спосіб моделювання типової ситуації, коли будь-яка дія, операція, функція можуть бути розбиті на більш прості дії, операції, функції. Іншими словами, складна бізнес-функція може бути представлена у вигляді сукупності елементарних функцій.

• Принцип обмеження складності. При роботі з IDEF0 діаграмами істотним є умова їхньої розбірливості. Суть принципу обмеження складності полягає в тому, що кількість блоків на діаграмі повинна бути не менш двох і не більш шести. Практика показує, що дотримання цього принципу приводить до того, що функціональні процеси, представлені у вигляді IDEF0 моделі, добре структуровані, зрозумілі і легко піддаються аналізу.
• Принцип контекстної діаграми. Моделювання ділового процесу починається з побудови контекстної діаграми. На цій діаграмі відображається тільки один блок - головна бізнес-функція системи. Якщо мова йде про моделювання цілого  підприємства чи навіть великого підрозділу, головна бізнес-функція не може бути сформульована як, наприклад, “продавати продукцію”. Головна бізнес-функція системи - це “місія” системи, її значення в навколишньому світі. Не можна правильно сформулювати головну функцію підприємства, не маючи представлення про його стратегію. При визначенні головної бізнес-функції необхідно завжди мати точку зору на модель. Те саме підприємство може бути описане по-різному, у залежності від того, з якого погляду його розглядають: директор підприємства і податкової інспектор бачать організацію зовсім по-різному. Контекстна діаграма грає ще одну роль у функціональній моделі. Вона “фіксує” границі бізнес- системи, визначаючи те, як система взаємодіє зі своїм оточенням. Це досягається за рахунок опису дуг, з'єднаних із блоком, що представляє головну бізнес-функцію.

1.3. Основні елементи і поняття IDEF0

Модель Idef0 складається з діаграм, фрагментів текстів, що мають посилання один на одного. Діаграми - головні компоненти моделі, усі функції ІС і інтерфейси на них представлені як блоки і дуги. Місце з'єднання дуги з блоком визначає тип інтерфейсу.

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

Графічна мова IDEF0 проста. В основі методології лежать чотири основних поняття:

Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (див. мал. 1) і уособлює собою деяку конкретну функцію в рамках розглянутої системи. По вимогах стандарту назва кожного функціонального блоку повинне бути сформульоване в дієслівному нахиленні (наприклад, “робити послуги”, а не “виробництво послуг”).

Кожна з чотирьох сторін функціонального блоку має своє визначене значення (роль), при цьому:

• Верхня сторона має значення “Керування” (Control); (стрілки зверху, що означають на підставі чого виконується даний процес - закони, стандарти, накази і т.д.);
• Ліва сторона має значення “Вхід” (Input); (стрілки ліворуч, - чи дані об'єкти, споживані чи змінювані процесом);
• Права сторона має значення “Вихід” (Output); (стрілки праворуч, - основні результати діяльності процесу, кінцеві продукти);
• Нижня сторона має значення “Механізм” (Mechanism). (стрілки знизу, що означають, за допомогою чого чи за допомогою кого реалізується даний процес - матеріальні і/чи кадрові ресурси, необхідні для процесу).

Кожен функціональний блок у рамках єдиної розглянутої системи повинен мати свій унікальний ідентифікаційний номер.

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

Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). За вимогою стандарту, найменування повинне бути іменником.

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

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

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

Обов'язкова наявність керуючих інтерфейсних дуг є одним з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

2. Побудова діаграм потоків даних (DFD)

2.1. Компоненти діаграм потоків даних.

2.2. Правила побудови моделі DFD.

2.3. Етапи побудови моделі DFD.

2.1. Компоненти діаграми потоків даних- DFD

Практично, на сьогоднішній день розрізняють дві графічні нотації для DFD (які і підтримуються Case-засобами): Гейна-Сарсона та Йордана-Де Марко, оскільки Де Марко в процесі удосконалення свого методу почав використовувати запропоновані Йорданом графічні зображення.

Основні символи цих нотацій зображені на рис 1. До них належать:

Назва	Нотація Йордона	Нотація Гейна-Сарсона
Flow – Потік даних
Process (bubble) - Процес
Store – Сховище	назва
Terminator – Зовнішній об’єкт	назва

Рисунок 1. Основні символи діаграм потоків даних

Потоки даних – під ними розуміють об’єкти (дані), що передаються з однієї частини системи в іншгу, позначаються стрілками. Стрілка вказує напрямок руху даних і може бути як одно-, так і двонаправленою.

Процеси – призначені для отримання вихідних потоків даних із вхідних, відповідно до дії, що задається ім’ям процесу (аналог робіт в IDEF0). Крім імені процес має також унікальний номер для посилань на нього усередині діаграми.

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

Зовнішній об’єкт - сутність поза контекстом системи, що є джерелом або приймачем системних даних. Її ім'я повинне містити іменник. Передбачається, що об'єкти, представлені такими вузлами, не повинні брати участь в обробці даних. Тобто, це не системний аналітик чи адміністратор і зв’язки між зовнішніми об’єктами на DFD не показуються.

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

Також здійснюється декомпозиція – спочатку процесу на контекстній діаграмі, а потім, на слідуючому рівні, й інших процесів. Процес декомпозиції продовжується доти, поки процеси можуть бути ефективно описані за допомогою коротких (до однієї сторінки) специфікацій – діаграм декомпозиції. Процеси нумеруються. Так, наприклад, якщо ми деталізуємо процес номер 2 на діаграмі першого рівня, розкриваючи його за допомогою DFD, що містить три процеси, то їхні номери будуть мати такий вигляд: 2.1, 2.2 і 2.3. Прості системи мабть 2-3 рівні декомпозиції, в складних їх зазвичай не більше восьми.

На рис.10.18. зображено взаємозв’язок діаграм потоків даних в нотації Йордана.

На рис.10.19. подано приклад діаграми декомпозиції в нотації DFD Гейна-Сарсона.

2.2. Правила побудови моделі DFD

Основними вимогами при побудові моделей DFD є:

· Розміщувати на кожній діаграмі від 3 до 6-7 процесів. Верхня границя відповідає людським можливостям одночасного сприйняття і розуміння структури складної системи, нижня границя обрана з позицій здорового глузду: немає необхідності деталізувати процес діаграмою, що містить всього один або два процеси.

· Не захаращувати діаграми несуттєвими на даному рівні деталями.

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

· Вибирати ясні імена процесів і потоків, для поліпшення розуміння діаграм, при цьому намагатися не використовувати абревіатури.

· Однократно визначати функціонально ідентичні процеси на самому верхньому рівні, де вони необхідні, і посилатися на них на нижніх рівнях.

· Користуватися найпростішими діаграмними техніками – не використовувати без необхідності складні об'єкти.

· Відокремлювати керуючі структури від процесів.

2.3 Етапи побудови моделі

Відповідно до цих рекомендацій процес побудови моделі розбивається на наступні етапи:

1. Розподіл множини вимог і організація їх в основні функціональні групи.

2. Ідентифікація зовнішніх об'єктів, з якими система повинна бути зв'язана.

3. Ідентифікація основних видів інформації, що циркулює між системою і зовнішніми об'єктами.

4. Розробка контекстної діаграми, на якій основні функціональні групи представляються процесами, зовнішні об'єкти - зовнішніми сутностями, основні види інформації - потоками даних між процесами і зовнішніми сутностями.

5. Формування DFD першого рівня на базі процесів попередньої контекстної діаграми, перевірка основних вимог по DFD першого рівня.

6. Декомпозиція кожного процесу поточної DFD за допомогою деталізуючої діаграми, або специфікації процесу, перевірка основних вимог по DFD відповідного рівня.

7. Додавання визначень нових потоків у словник даних при кожній їхній появі на діаграмах.

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

9. Після побудови двох-трьох рівнів проведення ревізії з метою перевірки коректності і поліпшення зрозумілості моделі.

Таким чином можна розробити логічну функціональну специфікацію системи – детальний опис того, що повинна робити система, незалежно від середовища реалізації.

3. Особливості побудови моделі за стандартом IDEF3

3.1.  Призначення IDEF3

3. 2. Типи діаграм в IDEF3

3.3. Позначення основних елементів моделі PFDD

3.4. Побудова OSTN діаграми

3.1. Призначення IDEF3

IDEF3 є стандартом документування технологічних процесів, що відбуваються на підприємстві, і надає інструментарій для наочного дослідження і моделювання їх сценаріїв.

Сценарієм (Scenario) ми називаємо опис послідовності змін властивостей об'єкту, в рамках даного процесу (наприклад, опис послідовності етапів обробки деталі в цеху і зміна її властивостей після проходження кожного етапу).

Виконання кожного сценарію супроводжується відповідним документообігом, який складається з двох основних потоків: документів, що визначають структуру і послідовність процесу (технологічних вказівок, описів стандартів і т.д.), і документів, що відображають хід його виконання (результатів тестів і експертиз, звітів про брак, і т.д.). Для ефективного управління будь-яким процесом, необхідно мати детальне уявлення про його сценарій і структуру супутнього документообігу. Засоби документування і моделювання IDEF3 дозволяють виконувати наступні завдання:

• Документувати наявні дані об технології процесу, виявлені, скажімо, в процесі опиту компетентних співробітників, відповідальних за організацію даного процесу.
• Визначати і аналізувати точки впливу потоків супутнього документообігу на сценарій технологічних процесів.
• Визначати ситуації, в яких потрібне ухвалення рішення, що впливає на життєвий цикл процесу, наприклад зміна конструктивних, технологічних або експлуатаційних властивостей кінцевого продукту.
• Сприяти ухваленню оптимальних рішень при реорганізації технологічних процесів.
• Розробляти імітаційні моделі технологічних процесів, за принципом "ЯК БУДЕ, ЯКЩО..."

3.2. Типи діаграм в IDEF3

Існують два типи діаграм в стандарті IDEF3, що представляють опис одного і того ж сценарію технологічного процесу в різних ракурсах. Діаграми відносяться до першого типу називаються діаграмами Опису Послідовності Етапів Процесу (Process Flow Description Diagrams, PFDD), а до другого - діаграмами Стану Об'єкту в і Етапів його Трансформацій (Object State Transition Network, OSTN). Припустимо, потрібно описати процес забарвлення деталі у виробничому цеху на підприємстві. За допомогою діаграм PFDD документується послідовність і опис стадій обробки деталі в рамках досліджуваного технологічного процесу. Діаграми OSTN використовуються для ілюстрації трансформацій деталі, які відбуваються на кожній стадії обробки.

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

Рисунок 1. Приклад PFDD діаграми.

На рис.1 зображена діаграма PFDD, що є графічним відображення сценарію обробки деталі.

3.3. Позначення основних елементів моделі PFDD

Прямокутники на діаграмі PFDD називаються функціональними елементами або елементами поведінки (Unit of Behavior, UOB) і позначають подію, стадію процесу або ухвалення рішення. Кожен UOB має своє ім'я, що відображається в дієслівному нахилі і унікальний номер. Стрілки або лінії є відображенням переміщення деталі між UOB-блоками в ході процесу.

Лінії бувають наступних видів:

- Головна (Precedence) - суцільніша лінія, зв'язуюча UOB. Малюється зліва направо або зверху вниз.

- Відносини (Relational Link) - пунктирна лінія, що використовується для зображення зв'язків між UOB

- Потоки об'єктів (Object Flow) - стрілка з двома наконечниками використовується для опису того факту, що об'єкт (деталь) використовується в двох або більш одиницях роботи, наприклад, коли об'єкт породжується в одній роботі і використовується в іншій.

Об'єкт, позначений J1 - називається перехрестям (Junction). Перехрестя використовуються для відображення логіки взаємодії стрілок (потоків) при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи.

Розрізняють перехрестя для злиття (Fan-in Junction) і розгалуження (Fan-out Junction) стрілок. Перехрестя не може використовуватися одночасно для злиття і для розгалуження. При внесенні перехрестя до діаграми необхідно вказати тип перехрестя.

Класифікація можливих типів перехресть приведена в таблиці.

Всі перехрестя в PFDD діаграмі нумеруються, кожен номер має префікс "J".

Сценарій, що відображається на діаграмі, можна описати в наступному вигляді:

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

Кожен функціональний блок UOB може мати послідовність декомпозицій, і, отже, може бути деталізований з будь-якою необхідною точністю. Під декомпозицією ми розуміємо представлення кожного UOB за допомогою окремої IDEF3 діаграми. Наприклад, ми можемо декомпозировать UOB "Офарбувати Деталь", представивши його окремим процесом і побудувавши для нього свою PFDD діаграму. При цьому ця діаграма називатиметься дочерней, по відношенню до зображеної на мал. 1, а та, відповідно батьківській. Номери UOB дочірніх діаграм мають крізну нумерацію, тобто, якщо батьківський UOB має номер "1", то блоки UOB на його декомпозиції відповідно матимуть номери "1.1", "1.2" і т.д. Застосування принципу декомпозиції в IDEF3 дозволяє структуровано описувати процеси з будь-яким необхідним рівнем деталізації.

3.4. Побудова OSTN діаграми

Рисунок 2. Приклад OSTN діаграми

Якщо діаграми PFDD технологічний процес "З погляду спостерігача", то інший клас діаграм IDEF3 OSTN дозволяє розглядати той же самий процес "З погляду об'єкту". На рис.2 представлено відображення процесу забарвлення з погляду OSTN діаграми. Стани об'єкту (у нашому випадку деталі) і Зміна стану є ключовими поняттями OSTN діаграми. Стани об'єкту відображаються колами, а їх зміни направленими лініями. Кожна лінія має посилання на відповідний функціональний блок UOB, в результаті якого відбулася зміна стану об'єкту, що відображалася нею.

4. Перелік літературних джерел

...

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

1. Що являє собою модель згідно методології IDEF0?
2. Для чого призначена контекстна діаграма?
3. З допомогою яких елементів зображають взаємодію системи з навколишнім середовищем?
4. Що означають функціональні блоки в методології IDEF0?
5. Яке призначення сторін функціональних блоків на діаграмах IDEF0?
6. Що називають граничними стрілками?
7. Опишіть процес декомпозиції роботи.
8. Що описує DFD-діаграма?
9. Перерахуйте складові частини DFD-діаграми.
10. В чому полягає призначення процесу?
11. Що таке зовнішня сутність?
12. Що описує сховище даних?
13. Для чого використовують методологію IDEF3?
14. Перелічіть елементи діаграм IDEF3.
15. Що показують зв’язку в діаграмах IDEF3?
16. Перелічіть типи стрілок у діаграмах IDEF3.
17. Що називається перехрестям? Назвіть типи перехресть.
18. Що називається об’єктом-посиланням?
19. Які бувають типи об’єктів-посилань?
20. Як додати об’єкт-посилання?