Основні стрілки в нотаціях idef0 та idef3

Тип стрілки	Графічне представлення
Стрілка попередника. З’єднує функції, що виконуються послідовно
Стрілка відношення. Використовується для прив’язки об’єктів-коментарів до функцій
Стрілка потоку об’єктів. Показує потік об’єктів від однієї функції до іншої

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

Перше з них – функціональний блок (Activity Box). Графічно він зображується у вигляді прямокутника, рис. 4.17 і уособлює в собі деяку конкретну функцію у рамках розглядуваної системи. За вимогами стандарту назва кожного функціонального блоку повинна бути виражена визначеною формою дієслова (наприклад, «виконувати послуги», а не «виконання послуг»). Кожна з чотирьох сторін функціонального блоку має своє певне значення:

• верхня сторона «Управління» (Control);

• ліва сторона «Вхід» (Input);

• права сторона «Вихід» (Output);

• нижня сторона «Механізм» (Mechanism).

Рис. 4.17. Функціональний блок

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

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

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

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

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

Рис. 4.18. Функціональний блок «Коригувати технологічні вказівки»

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

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

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

Модель IDEF0 завжди починається з представлення системи як єдиного цілого – одного функціонального блоку з інтерфейс ними дугами, що простягаються за межі розглядуваної області. Така діаграма з одним функціональним блоком називається контекстною діаграмою і позначається ідентифікатором «А-0». У пояснювальному тексті до діаграми повинна бути вказана мета (Purpose) побудови діаграми (у вигляді короткого опису) та зафіксована точка зору (Viewpoint).

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

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

У процесі декомпозиції функціональний блок, який у контекстній діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Отримана діаграма другого рівня містить функціональні блоки, що відображають головні під функції функціонального блоку контекстної діаграми і називається дочірньою (Child Diagram) по відношенню до нього (кожний із функціональних блоків, що належить дочірній діаграмі, відповідно називається «дочірнім блоком» – Child Box). У свою чергу функціональний блок-предок називається «батьківським блоком» (Parent Box) по відношенню до дочірньої діаграми, а діаграма, якій він належить – «батьківською діаграмою» (Parent Diagram). Кожна з підфункцій дочірньої діаграми може бути й далі деталізована шляхом аналогічної декомпозиції функціонального блоку, що їй відповідає. Важливо відмітити, що в кожному випадку декомпозиції функціонального блоку усі інтерфейсні дуги, що входять в даний блок чи виходять з нього, фіксуються на дочірній діаграмі. Цим досягається структурна цілісніть IDEF0-моделі. Наглядно принцип декомпозиції представлено на рис. 4.19. Слід звернути увагу на взаємозв’язок нумерації функціональних блоків та діаграм – кожний блок має свій унікальний порядковий номер на діаграмі (цифра в правому нижньому куті прямокутника), а під правим кутом вказують номер дочірньої для цього блоку діаграми. Відсутність такого позначення говорить про те, що декомпозиції для даного блоку не існує.

Рис. 4.19. Декомпозиція функціональних блоків

Часто бувають випадки, коли окремі інтерфейсні дуги не має змісту продовжувати розглядати у дочірніх діаграмах нижче якогось певного рівня в ієрархії, чи навпаки – окремі дуги не мають практичного змісту вище якогось рівня. Наприклад, інтерфейсну дугу, що зображає «деталь» на вході у функціональний блок «Обробити на токарному станку», не має змісту зображати на діаграмах більш високих рівнів – це буде тільки перевантажувати діаграми і робити їх складнішими для сприйняття. З іншого боку, іноді виникає необхідність позбутися від окремих «концептуальних» інтерфейс них дуг і не деталізувати їх глибше деякого рівня. для вирішення подібних задач у стандарті IDEF0 передбачено поняття тунелювання. Зображення «тунелю» (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги означає, що ця дуга не була унаслідувана від функціонального батьківського блоку і з’явилася (з «тунелю») тільки на цій діаграмі. У свою чергу таке ж зображення навколо кінця (стрілки) інтерфейсної дуги безпосередньо біля блоку-приймача означає той факт, що у дочірній по відношенню до цього блоку діаграмі ця дуга відображатися та розглядатися не буде. Частіше за все буває, що окремі об’єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії – в такому випадку вони спочатку «занурюються в тунель», а потім при необхідності «повертаються з тунелю».

Останнім з понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0 – діаграм, функціональних блоків, інтерфейсних дуг – існуючий стандарт передбачає створення та підтримку набору відповідних визначень, ключових слів, коротких описів та ін., які характеризують об’єкт, відображений даним елементом. Цей набір називається глосарієм і є описанням сутності даного елементу. Наприклад, для управляючої інтерфейсної дуги «розпорядження про оплату» глосарій може містити перелік полів документа, що відповідає дузі, необхідний набір віз і т.д. Глосарій гармонічно доповнює наглядну графічну мову, надаючи діаграмі необхідну додаткову інформацію.

Зазвичай IDEF0-моделі несуть в собі складну і концентровану інформацію, і для того, щоб обмежити їх перевантаженість та зробити зручними для сприймання, у відповідному стандарті прийняті відповідні обмеження складності:

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

• Обмеження для одного функціонального блоку вхідних та вихідних дуг чотирма.

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

• Створення моделі групою фахівців, що відносяться до різних сфер діяльності підприємства. Ця група в термінах IDEF0 називається авторами (Authors). В ході побудови початкової моделі автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів та результатів опитування створюється чернетка (Model Draft) моделі.

• Розповсюдження чернетки для розгляду, узгодження та коментарів. На цій стадії відбувається обговорення чернетки моделі з широким спектром компетентних осіб (в термінах IDEF0 – «читачів») на підприємстві. При цьому кожна з діаграм чорнової моделі письмово критикується та коментується, після чого передається автору. Автор, в свою чергу, також письмово погоджується з критикою чи відхиляє її з викладенням логіки прийняття рішення і знову повертає відкореговану чернетку для подальшого розгляду. Цей цикл продовжується доти, поки автори та читачі не прийдуть до єдиної думки.

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

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