Знайомство з нотацією IDEF0 та приклад використання. Методологія функціонального моделювання idef0 Загальні відомості про методологію idef0
Методологія IDEF0
Методологія IDEF0наказує побудова ієрархічної системи діаграм - одиничних описів фрагментів системи. Спочатку проводиться опис системи в цілому та її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція – система розбивається на підсистеми та кожна підсистема описується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається більш дрібні тощо до досягнення потрібного ступеня подробиці.
Кожна IDEF0-діаграмамістить блоки та дуги. Блоки зображують функції системи, що моделюється. Дуги зв'язують блоки разом і відображають взаємодії та взаємозв'язки між ними.
Функціональні блоки (роботи) на діаграмах зображуються прямокутниками, що означають пойменовані процеси, функції або завдання, які відбуваються протягом певного часу і мають результати, що розпізнаються. Ім'я роботи має бути виражене віддієслівним іменником, що позначає дію.
IDEF0вимагає, щоб у діаграмі було щонайменше трьох і трохи більше шести блоків. Ці обмеження підтримують складність діаграм та моделі на рівні, доступному для читання, розуміння та використання.
Кожна сторона блоку має особливе, цілком певне призначення. Ліва сторона блоку призначена для входів, верхня – для керування, права – для виходів, нижня – для механізмів. Таке позначення відбиває певні системні принципи: входи перетворюються на виходи управління обмежує чи приписує умови виконання перетворень, механізми показують, як і виконує функція.
Блоки IDEF0 розміщуються за рівнем важливості, як її розуміє автор діаграми. Цей відносний лад називається домінуванням. Домінування розуміється як вплив, який один блок чинить інші блоки діаграми. Наприклад, домінуючим блоком діаграми може бути або перший з необхідної послідовності функцій, або плануюча або контролююча функція, що впливає на всі інші.
Найбільш домінуючий блок зазвичай розміщується у верхньому лівому куті діаграми, а найменування домінуючий - у правому кутку.
Розташування блоків на сторінці відбиває авторське визначення домінування. Таким чином, топологія діаграми показує, які функції мають більший вплив на інші. Щоб підкреслити це, аналітик може перенумерувати блоки відповідно до порядку їхнього домінування. Порядок домінування може позначатись цифрою, розміщеною в правому нижньому куті кожного прямокутника: 1 вказуватиме на найбільше домінування, 2 – на наступне і т.д.
Взаємодія робіт із зовнішнім світом і між собою описується у вигляді стрілок, що зображуються одинарними лініями зі стрілками на кінцях. Стрілки є якоюсь інформацією і називаються іменниками.
У IDEF0 розрізняють п'ять типів стрілок.
Вхід- об'єкти, що використовуються та перетворюються роботою для отримання результату (виходу). Допускається, що робота може мати жодної стрілки входу. Стрілка входу малюється як входить у ліву грань роботи.
Управління-.інформація, керуюча діями роботи. Зазвичай стрілки, що управляють, несуть інформацію, яка вказує, що повинна виконувати робота. Кожна робота повинна мати хоча б одну стрілку управління, яка зображується як вхідна у верхню межу роботи.
Вихід- Об'єкти, в які перетворюються входи. Кожна робота повинна мати хоча б одну стрілку виходу, яка малюється як вихідна з правої грані роботи.
Механізм- Ресурси, що виконують роботу. Стрілка механізму малюється як входить у нижню грань роботи. На розсуд аналітика стрілки механізму можуть не зображуватися на моделі.
Виклик- Спеціальна стрілка, що вказує на іншу модель роботи. Стрілка виклику малюється як вихідна з нижньої частини роботи і використовується для вказівки того, що деяка робота виконується за межами системи, що моделюється.
Мал. 2.1Типи стрілок
У методології IDEF0 потрібно лише п'ять типів взаємодій між блоками для опису їхніх відносин: керування, вхід, зворотний зв'язок з управління, зворотний зв'язок по входу, вихід-механізм. Зв'язки з управління та входу є найпростішими, оскільки вони відображають прямі дії, які інтуїтивно зрозумілі та дуже прості.
Мал. 2.2.Зв'язок по виходу
Мал. 2.3.Зв'язок з управління
Відношення управління виникає тоді, коли вихід одного блоку безпосередньо впливає на блок із меншим домінуванням.
Зворотний зв'язок з управління і зворотний по входу є складнішими, оскільки є ітерацію чи рекурсію. А саме виходи з однієї роботи впливають на майбутнє виконання інших робіт, що вплине на вихідну роботу.
Зворотний зв'язок з управління виникає тоді; коли вихід деякого блоку впливає блок із великим домінуванням.
Зв'язки «вихід-механізм» трапляються нечасто. Вони відображають ситуацію, коли вихід однієї функції стає засобом досягнення мети для іншої.
Мал. 2.4.Зворотній зв'язок по входу
Мал. 2.5.Зворотній зв'язок з управління
Зв'язки «вихід-механізм» притаманні розподілу джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, обладнання, фінансування, матеріали).
У IDEF0 дуга рідко зображує один об'єкт. Зазвичай вона символізує набір об'єктів. Оскільки дуги представляють набори об'єктів, можуть мати безліч початкових точок (джерел) і кінцевих точок (призначень). Тому дуги можуть розгалужуватися та з'єднуватися різними способами. Вся дуга або її частина може виходити з одного або кількох блоків та закінчуватися в одному або кількох блоках.
Розгалуження дуг, що зображується у вигляді ліній, що розходяться, означає, що весь вміст дуг або його частина може з'явитися в кожному відгалуженні. Дуга завжди позначається до розгалуження, щоб дати назву всьому набору. Крім того, кожна гілка дуги може бути позначена або не позначена відповідно до таких правил:
непомічені гілки містять вагу об'єкти, вказані в мітці дуги перед розгалуженням;
гілки, позначені після точки розгалуження, містять усі об'єкти або їхню частину, зазначені в мітці дуги перед розгалуженням.
Злиття дуг в IDEFO, що зображується як лінії, що сходяться разом, вказує, що вміст кожної гілки йде на формування мітки для дуги, що є результатом злиття вихідних дуг. Після злиття результуюча дуга завжди позначається для вказівки нового набору об'єктів, що виник після об'єднання. Крім того, кожна гілка перед злиттям може позначатися або не позначатися відповідно до таких правил:
Мал. 2.6.Зв'язок вихід-механізм
непомічені гілки містять вагу об'єкти, зазначені у загальній мітці дуги після злиття;
помічені перед злиттям гілки містять усі або деякі об'єкти з перерахованих у загальній мітці після злиття,
кількість блоків на діаграмі - N;
рівень декомпозиції діаграми - L;
збалансованість діаграми - В;
число стрілок, що з'єднуються з блоком, - А
Цей набір факторів відноситься до кожної діаграми моделі. Далі будуть перераховані рекомендації щодо бажаних значень факторів діаграми.
Необхідно прагнути до того, щоб кількість блоків на діаграмах нижніх рівнів була б нижчою за кількість блоків на батьківських діаграмах, тобто зі збільшенням рівня декомпозиції зменшувався б коефіцієнт. Таким чином, спад цього коефіцієнта говорить про те. що в міру декомпозиції моделі функції повинні спрощуватися, отже, кількість блоків має зменшуватися.
Діаграми мають бути збалансовані. Це означає, що у межах однієї діаграми має відбуватися ситуації, зображеної на рис. 2.7: у роботи 1 вхідних стрілок і стрілок управління значно більше ніж виходять. Слід зазначити, що ця рекомендація може виконуватися в моделях, описують виробничі процеси. Наприклад, при описі процедури збирання блок може входити безліч стрілок, що описують компоненти виробу, а виходити одна стрілка - готовий виріб.
Мал. 2.7.Приклад незбалансованої діаграми
Введемо коефіцієнт збалансованості діаграми
Необхідно прагнути, щоб Кьбув мінімальним для діаграми.
Крім аналізу графічних елементів діаграми слід розглядати найменування блоків. Для оцінки імен складається словник елементарних (тривіальних) функцій системи, що моделюється. Фактично в даний словникповинні потрапити функції нижнього рівня декомпозиції діаграм. Наприклад, для моделі БД елементарними можуть бути функції «знайти запис», «додати запис БД», тоді як функція «реєстрація користувача» вимагає подальшого опису.
Після формування словника та складання пакета діаграм системи необхідно розглянути нижній рівень моделі. Якщо на ньому виявляться збіги назв блоків діаграм і слів зі словника, це говорить, що достатній рівень декомпозиції досягнутий. Коефіцієнт, який кількісно відображає даний критерій, можна записати як L * C -добуток рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.
При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.
При створенні нової моделі виникає діалог, у якому слід зазначити, чи буде створена модель заново, чи вона буде відкрита з репозиторію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).
Рис.2.8Діалог створення моделі
BPWin підтримує три методології - IDEF0, IDEF3 та DFD. У BPWin можлива побудова змішаних моделей, тобто модель може містити одночасно діаграми IDEF0, так і IDEF3 і DFD. Склад панелі інструментів автоматично змінюється, коли відбувається перемикання з однієї нотації на іншу.
Модель у BPWin розглядається як сукупність робіт, кожна з яких оперує з деяким набором даних. Якщо клацнути на будь-якому об'єкті моделі лівою кнопкою миші, з'являється спливаюче контекстне меню, кожен пункт якого відповідає редактору будь-якої властивості об'єкта.
Побудова моделі системи має починатися з вивчення всіх документів, що її описують функціональні можливості. Одним із таких документів є технічне завдання, а саме розділи "Призначення розробки", "Цілі та завдання системи" та "Функціональні характеристики системи".
Після вивчення вихідних документів та опитування замовників та користувачів системи необхідно сформулювати мету моделювання та визначити точку зору на модель. Розглянемо технологію її побудови на прикладі системи "Служба зайнятості в рамках ВНЗ", основні можливості якої були описані у лабораторній роботі №1.
Сформулюємо мету моделювання: описати функціонування системи, яке було б зрозуміле її користувачу, не вдаючись у подробиці, пов'язані з реалізацією. Модель будуватимемо з погляду користувачів (студент, викладач, адміністратор, деканат, фірма).
Почнемо з побудови контекстної IDEF0-діаграми. Згідно з описом системи основною функцією є обслуговування її клієнтів за допомогою обробки запитів, що від них надходять. Отже, визначимо єдину роботу контекстної діаграми як «Обслуговувати клієнта системи». Далі визначимо вхідні та вихідні дані, а також механізми та управління.
Для того, щоб обслужити клієнта, необхідно зареєструвати його в системі, відкрити доступ до БД та опрацювати його запит. Як вхідні дані використовуватимуться «ім'я клієнта», «пароль клієнта», «вихідна БД», «запит клієнта». Виконання запиту веде або до отримання інформації від системи, або зміни вмісту БД (наприклад, при складанні експертних оцінок), тому вихідними даними будуть «звіти» і «змінена БД». Процес обробки запитів виконуватиме монітор системи під контролем адміністратора.
Отже, визначимо контекстну діаграму системи (рис. 2.9).
Рис. 2.9.Контекстна діаграма системи
Проведемо декомпозицію контекстної діаграми, описавши послідовність обслуговування клієнта:
Визначення рівня доступу до системи.
Вибір підсистеми.
Звернення до підсистеми.
Зміна БД (за потреби).
Отримаємо діаграму, зображену на рис. 2.10.
Закінчивши декомпозицію контекстної діаграми, переходять до декомпозиції діаграми наступного рівня. Зазвичай при розгляді третього та нижчих рівнів моделі повертаються до батьківських діаграм і коригують їх.
Мал. 2.10.Декомпозиція роботи "Обслуговування, клієнта системи"
Декомпозуємо послідовно всі блоки отриманої діаграми. Першим етапом щодо рівня доступу до системи є визначення категорії пользователя. На ім'я клієнта здійснюється пошук у базі користувачів, визначаючи його категорію. Відповідно до певної категорії з'ясовуються повноваження, що надаються користувачеві системи. Далі проводиться процедура доступу до системи, перевіряючи ім'я та пароль доступу. Поєднуючи інформацію про повноваження та рівень доступу до системи, для користувача формується набір дозволених дій. Таким чином, визначення рівня доступу до системи виглядатиме як показано на рис. 2.11.
Мал. 2.11.Декомпозиція роботи «Визначення рівня доступу до системи»
Після проходження процедури доступу до системи монітор аналізує запит клієнта, вибираючи підсистему, яка оброблятиме запит. Декомпозиція роботи «Звернення до підсистеми» не відповідає меті та точці зору моделі. Користувача системи не цікавлять внутрішні алгоритми її роботи. В даному випадку йому важливо, що вибір підсистеми буде зроблено автоматично, без його втручання, тому декомпозиція звернення до підсистеми ускладнить модель.
Декомпозуємо роботу «Обробка запиту клієнта», що виконується підсистемою обробки запитів, визначення категорій та повноважень користувачів. Перед пошуком відповіді на запит необхідно відкрити БД (підключитися до неї). У загальному випадку БД може перебувати на віддаленому сервері, тому може знадобитися встановлення з'єднання з нею. Визначимо послідовність робіт:
Відкриття БД.
Виконання запиту.
генерація звітів.
Після відкриття БД необхідно повідомити систему встановлення з'єднання з БД, після чого виконати запит і згенерувати звіти для користувача (рис. 2.12).
Слід зазначити, що у «Виконання запиту» включається робота різних підсистем. Наприклад, якщо запит включає тестування, то його буде виконувати підсистема професійних і психологічних тестів. На етапі виконання запиту може знадобитися зміна вмісту БД, наприклад, при складанні експертних оцінок. Тому на діаграмі необхідно передбачити таку можливість.
Мал. 2.12.
Під час аналізу отриманої діаграми виникає питання, за якими правилами відбувається генерація звітів? Необхідна наявність заздалегідь сформованих шаблонів, за якими проводитиметься вибірка з БД, причому ці шаблони повинні відповідати запитам і повинні бути заздалегідь визначені. Крім того, клієнту має бути надана можливість вибору форми звіту.
Скоригуємо діаграму, додавши до неї стрілки «Шаблони звітів» та «Запити на зміну БД» та тунельну стрілку «Клієнт системи». Тунелювання «Клієнта системи» застосовано для того, щоб не виносити стрілку на діаграму верхнього, тому що функція вибору форми звіту не є достатньо важливою для відображення її на батьківській діаграмі.
Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 – 2.15).
Декомпозицію роботи «Виконання запиту» доцільно провести з допомогою діаграми DFD (лабораторна робота № 3), оскільки методологія IDEF0 розглядає систему як сукупність взаємозалежних робіт, що негативно відбиває процеси обробки інформації.
Мал. 2.13.Декомпозиція роботи "Обробка запиту клієнта"
Мал. 2.14.Декомпозиція роботи «Обслуговування клієнта системи» (варіант 2)
Мал. 2.15.Контекстна діаграма системи (варіант 2)
Перейдемо до декомпозиції останнього блоку «Зміна БД». З погляду клієнта, ці системи розташовуються в одній БД. Реально в системі присутні шість БД:
БД користувачів,
БД студентів, (варіант 2)
БД вакансій
БД успішності,
БД тестів,
БД експертних оцінок,
БД резюме.
Відповідно до мети моделювання клієнту важливо розуміти, що дані, що надійшли, не відразу оновлюються в системі, а проходять додатковий етап обробки та контролю. Алгоритм зміни можна сформулювати так:
Визначається БД, у якій змінюватиметься інформація.
Оператором формується тимчасовий набір даних та надається адміністратору.
Адміністратор здійснює контроль даних та вносить їх до БД.
Дану модель реалізувати в інший спосіб, надавши можливість оновлення БД безпосередньо за запитами, минаючи процес контролю даних. І тут необхідно забезпечити контроль цілісності БД щоб уникнути її ушкодження. У цьому випадку діаграма буде виглядати так (рис. 2.17).
Мал. 2.16.Декомпозиція роботи «Зміна БД»
Мал. 2.17.Декомпозиція роботи "Зміна БД" (варіант 2) Для першого варіанту, зображеного на рис. 2.12
Проведення подальшої декомпозиції «Зміни БД» ускладнюватиме модель, пояснюючи, як здійснюється фізична зміна БД у системі. При цьому користувач не отримає жодної додаткової інформації щодо роботи системи служби зайнятості. Декомпозицію цієї роботи доцільно проводити у процесі проектування БД системи на етапі створення логічної моделі БД.
Декомпозицію роботи «Виконання запиту» буде проведено у наступній лабораторній роботі, ілюструючи застосування діаграм DFD для опису процесів обробки інформації.
Проведемо кількісний аналіз моделей, зображених на рис. 2.12 та 2.13, згідно з вищеописаною методикою. Розглянемо поведінку коефіцієнта у цих моделей. У батьківської діаграми «Обробка запиту клієнта» коефіцієнт дорівнює 4/2 = 2, а діаграми декомпозиції 3/3 = 1. Значення коефіцієнта зменшується, що свідчить про спрощення описи функцій зі зниженням рівня моделі.
Розглянемо зміну коефіцієнта До b у двох варіантів моделей.
для другого варіанта
Коефіцієнт До b не змінює свого значення, отже, збалансованість діаграми змінюється.
Вважатимемо, що рівень декомпозиції розглянутих діаграм достатній для відображення мети моделювання, і на діаграмах нижнього рівня як найменування робіт використовуються елементарні функції (з точки зору користувача системи).
Підбиваючи підсумки розглянутого прикладу необхідно відзначити важливість розгляду кількох варіантів діаграм при моделюванні системи. Такі варіанти можуть виникати під час коригування діаграм, як це було зроблено з «Обробкою запиту клієнта» або під час створення альтернативних реалізацій функцій системи (декомпозиція роботи «Зміна БД»). Розгляд варіантів дозволяє вибрати найкращий та включити його в пакет діаграм для подальшого розгляду.
6.2. Призначення та склад методології SADT (IDEF0)Методологія SADT (Structured Analysis and Design Technique – методологія структурного аналізу та проектування) є сукупністю методів, правил і процедур, призначених для побудови функціональної моделі системи.
Початок розробки даної методології було покладено Дугласом Россом (США) у середині 60-х років. ХХ ст. З того часу системні аналітики компанії SofTech, Inc. покращили SADT і використали її у вирішенні широкого кола проблем. Програмне забезпечення телефонних мереж, діагностика, довгострокове та стратегічне планування, автоматизоване виробництво та проектування, конфігурація комп'ютерних систем, навчання персоналу, управління фінансами та матеріально-технічним постачанням – ось деякі з областей ефективного застосування SADT. Широкий спектр областей вказує на універсальність та потужність методології SADT. У програмі «Інтеграції комп'ютерних та промислових технологій» (Integrated Computer Aided Manufacturing, ICAM) Міністерства оборони США було визнано корисність SADT. Це призвело до публікації її частини в 1981 р. IDEF0 (Icam DEFinition), як федеральний стандарт на розробку програмного забезпечення. Під цією назвою SADT стала застосовуватись тисячами фахівців у військових та промислових організаціях. Остання редакція стандарту IDEF0 було випущено грудні 1993г. Національним інститутом зі стандартів та технологій США (National Institute Standards and Technology, NIST).
Ця методологія при описі функціонального аспекту інформаційної системиконкурує із методами, орієнтованими на потоки даних (DFD). На відміну від них IDEF0 дозволяє:
Описувати будь-які системи, а не лише інформаційні (DFD призначена для опису програмного забезпечення);
Створити опис системи та її зовнішнього оточення до визначення остаточних вимог до неї. Іншими словами, за допомогою даної методології можна поступово вибудовувати та аналізувати систему навіть тоді, коли важко ще уявити її втілення.
Таким чином, IDEF0 може застосовуватись на ранніх етапахстворення широкого загалу систем. У той же час вона може бути використана для аналізу функцій існуючих систем та вироблення рішень щодо їх поліпшення.
Основою методології IDEF0 є графічна мова опису процесів. Модель у нотації IDEF0 є сукупністю ієрархічно впорядкованих і взаємопов'язаних діаграм. Кожна діаграма є одиницею опису системи та розташовується на окремому аркуші.
Модель (AS-IS, TO-BE або SHOULD-BE) може містити 4 типи діаграм [ , ]:
Контекстну діаграму;
діаграми декомпозиції;
Діаграми дерева вузлів;
Діаграми лише для експозиції (for exposition only, FEO).
Контекстна діаграма (Діаграма верхнього рівня), будучи вершиною деревоподібної структури діаграм, показує призначення системи (основну функцію) та її взаємодію із зовнішнім середовищем. У кожній моделі може бути лише одна контекстна діаграма. Після опису основної функції виконується функціональна декомпозиція, т. е. визначаються функції, у тому числі складається основна.
Далі функції діляться на підфункції і до досягнення необхідного рівня деталізації досліджуваної системи. Діаграми, які описують кожен такий фрагмент системи, називаються діаграмами декомпозиції . Після кожного сеансу декомпозиції проводяться сеанси експертизи – експерти предметної галузі свідчать про відповідність реальних процесів створеним діаграмам. Знайдені невідповідності усуваються, після чого приступають до подальшої деталізації процесів.
Діаграма дерева вузлів показує ієрархічну залежність функцій (робіт), але з зв'язку з-поміж них. Їх може бути кілька, оскільки дерево можна побудувати на довільну глибину та з довільного вузла.
Діаграми для експозиції будуються для ілюстрації окремих фрагментів моделі з метою відображення альтернативної точки зору на процеси, що відбуваються в системі (наприклад, з точки зору керівництва організації).
6.3. Елементи графічної нотації IDEF0
Методологія IDEF0 знайшла широке визнання та застосування, в першу чергу, завдяки простій графічній нотації, що використовується для побудови моделі. Основними компонентами моделі є діаграми. На них відображаються функції системи у вигляді прямокутників, а також зв'язки між ними та зовнішнім середовищем за допомогою стрілок. Використання лише двох графічних примітивів (прямокутник і стрілка) дозволяють швидко пояснити правила та принципи побудови діаграм IDEF0 людям, незнайомим з даною методологією. Ця перевага дозволяє підключити та активізувати діяльність замовника з опису бізнес-процесів з використанням формального та наочного графічної мови.
На наступному малюнку показано основні елементи графічної нотації IDEF0.
Мал. 6.1. Елементи графічної нотації IDEF0
Прямокутник є роботу (процес, діяльність, функцію чи завдання) яка має фіксовану мету і призводить до деякого кінцевого результату. Ім'я роботи має виражати дію (наприклад, «Виготовлення деталі», «Розрахунок допустимих швидкостей», «Формування відомості ЦДЛ № 3»).
Взаємодія робіт між собою та зовнішнім світом описується у вигляді стрілок. У IDEF0 розрізняють 5 видів стрілок :
- Вхід (англ. input) – матеріал або інформація, які використовуються та перетворюються роботою для отримання результату (виходу). Вхід відповідає питанням «Що підлягає обробці?». Як вход може бути як матеріальний об'єкт (сировина, деталь, екзаменаційний квиток), так і не має чітких фізичних контурів (запит до БД, питання викладача). Допускається, що робота може мати жодної стрілки входу. Стрілки входу завжди малюються що входять у ліву грань роботи;
- управління (англ. control) – керуючі, які регламентують та нормативні дані, якими керується робота. Управління відповідає питанням «Відповідно до чого виконується робота?». Управління впливає роботу, але з перетворюється їй, тобто. виступає як обмеження. Як управління може бути правила, стандарти, нормативи, розцінки, усні вказівки. Стрілки управління малюються що входять у верхню межу роботи. Якщо при побудові діаграми виникає питання, як правильно намалювати стрілку згори або зліва, то рекомендується її малювати як вхід (стрілка зліва);
- вихід (англ. output) – матеріал чи інформація, які представляють результат виконання. Вихід відповідає питанням «Що є результатом роботи?». Як вихід може бути як матеріальний об'єкт (деталь, автомобіль, платіжні документи, відомість), і нематеріальний (вибірка даних із БД, у відповідь питання, усне указание). Стрілки виходу малюються що виходять із правої межі роботи;
- механізм (англ. mechanism) - ресурси, які виконують роботу. Механізм відповідає питанням «Хто виконує роботу чи з допомогою чого?». Як механізм можуть бути персонал підприємства, студент, верстат, обладнання, програма. Стрілки механізму малюються що входять у нижню грань роботи;
- виклик (англ. call) - стрілка вказує, що деяка частина роботи виконується за межами розглянутого блоку. Стрілки виходу малюються вихідними з нижньої межі роботи.
6.4. Типи зв'язків між роботами
Після визначення складу функцій та взаємозв'язків між ними виникає питання про правильну їх композицію (об'єднання) в модулі (підсистеми). При цьому мається на увазі, що кожна окрема функція повинна вирішувати одну, суворо конкретну задачу. В іншому випадку необхідна подальша декомпозиція або розподіл функцій.
При об'єднанні функцій у підсистеми необхідно прагнути, щоб внутрішня зв'язність (між функціями всередині модуля) була якомога сильнішою, а зовнішня (між функціями, що входять у різні модулі), якомога слабшою. Спираючись на семантику зв'язків методології, запровадимо класифікацію зв'язків між функціями (роботами). Ця класифікація є розширенням. Типи зв'язків наводяться у порядку зменшення їхньої значущості (сили зв'язування). У прикладах потовщеними лініями виділяються функції, між якими є аналізований тип зв'язку.
1. Ієрархічний зв'язок (зв'язок «частина» – «ціле») має місце між функцією та підфункціями, з яких вона складається.
Мал. 6.2. Ієрархічний зв'язок
2. Регламентуючий (керуючий, підпорядкований) зв'язок відображає залежність однієї функції від іншої, коли вихід однієї роботи прямує на керування іншою. Функцію, з якої виходить керування, слід вважати регламентуючої або керуючої, а в яку входить - підлеглою. Розрізняють прямий зв'язок з управління , коли управління передається з вищестоящої роботи на нижчестоящу (рис. 6.3), та Зворотній зв'язокз управління , коли керування передається від нижчестоящої до вищестоящої (рис. 6.4).
3. Функціональний (технологічний) зв'язок має місце, коли вихід однієї функції є вхідними даними для наступної функції. З погляду потоку матеріальних об'єктів даний зв'язокпоказує технологію (послідовність робіт) обробки цих об'єктів. Розрізняють прямий зв'язок по входу , коли вихід передається з вищої роботи на нижчестоящу (рис. 6.5), та зворотний зв'язок по входу коли вихід передається з нижчестоящої до вищестоящої (рис.6.6).
 |
 |
| Мал. 6.5. Прямий зв'язок по входу | Мал. 6.6. Зворотній зв'язок по входу |
4. Споживчий зв'язок має місце, коли вихід однієї функції служить механізмом наступної функції. Таким чином, одна функція споживає ресурси, що виробляються іншою.
Мал. 6.7. Споживчий зв'язок
5. Логічний зв'язок спостерігається між логічно однорідними функціями. Такі функції, як правило, виконують ту саму роботу, але різними (альтернативними) способами або, використовуючи різні вихідні дані (матеріали).
Мал. 6.8. Логічний зв'язок
6. Колегіальний (методичний) зв'язок має місце між функціями, алгоритм роботи яких визначається одним і тим самим управлінням. Аналогом такого зв'язку є спільна роботаспівробітників одного відділу (колег), які підпорядковуються начальнику, який віддає вказівки та накази (керівні сигнали). Такий зв'язок також виникає, коли алгоритми роботи цих функцій визначаються тим самим методичним забезпеченням (СНІП, ГОСТ, офіційними нормативними матеріалами і т. д.), що служить як управління.
Мал. 6.9. Методичний зв'язок
7. Ресурсний зв'язок виникає між функціями, що використовують для своєї роботи одні й самі ресурси. Ресурсно-залежні функції, зазвичай, що неспроможні виконуватися одночасно.
Мал. 6.10. Ресурсний зв'язок
8. Інформаційний зв'язок має місце між функціями, що використовують як вхідні дані одну і ту ж інформацію.
Мал. 6.11. Інформаційний зв'язок
9. Тимчасовий зв'язок виникає між функціями, які мають виконуватися одночасно до або одночасно після іншої функції.
Крім зазначених на малюнку випадків, цей зв'язок має місце між іншими поєднаннями управління, входу і механізму, що надходять в одну функцію.
Мал. 6.12. Тимчасовий зв'язок
10. Випадковий зв'язок виникає, коли конкретна зв'язок між функціями мала чи повністю відсутня.
Мал. 6.13. Випадковий зв'язок
З наведених вище типів зв'язків найбільш сильним є ієрархічний зв'язок, який, по суті, визначає об'єднання функцій у модулі (підсистеми). Дещо слабшими є регламентуючі, функціональні та споживчі зв'язки. Функції із цими зв'язками зазвичай реалізуються лише у підсистемі. Логічні, колегіальні, ресурсні та інформаційні зв'язки одні з найслабших. Функції, які мають, як правило, реалізують у різних підсистемах, крім логічно однорідних функцій (функцій, пов'язаних логічним зв'язком). Тимчасовий зв'язок свідчить про слабку залежність функцій друг від друга і вимагає реалізації в окремих модулях.
Таким чином, при поєднанні функцій у модулі найбільш бажаними є перші п'ять видів зв'язків. Функції, пов'язані останніми п'ятьма зв'язками, краще реалізовувати окремих модулях.
У IDEF0 існують угоди (правила та рекомендації) щодо створення діаграм, які покликані полегшити читання та експертизу моделі [ , ]. Деякі з цих правил CASE-кошти підтримують автоматично, виконання інших слід забезпечити вручну.
1. Перед побудовою моделі необхідно визначитись, яка модель (моделі) системи буде побудована. Це означає визначення її типу AS-IS, TO-BE або SHOULD-BE, і навіть визначення позиції, з погляду якої будується модель. «Точку зору» найкраще уявляти собі як місце (позицію) людини або об'єкта, в яке треба стати, щоб побачити систему в дії. Наприклад, при побудові моделі роботи продуктового магазину можна серед можливих претендентів, з погляду яких розглядається система, вибрати продавця, касира, бухгалтера чи директора. Зазвичай вибирається одна точка зору, що найбільш повно охоплює всі нюанси роботи системи, і при необхідності для деяких діаграм декомпозиції будуються діаграми FEO, що відображають альтернативну точку зору.
2. На контекстній діаграмі відображається один блок, який показує призначення системи. Для нього рекомендується відображати по 2–4 стрілки, що входять та виходять з кожного боку.
3. Кількість блоків на діаграмах декомпозиції рекомендується в межах 3-6. Якщо діаграмі декомпозиції два блоки, вона, зазвичай, немає сенсу. За наявності великої кількості блоків діаграма стає перенасиченою і важко читається.
4. Блоки на діаграмі декомпозиції слід розташовувати зліва направо та зверху донизу. Таке розташування дозволяє більш чітко відобразити логіку та послідовність виконання робіт. Окрім цього маршрути стрілок будуть менш заплутаними та матимуть мінімальну кількість перетинів.
5. Відсутність функції одночасно стрілок управління і входу не допускається. Це означає, що запуск цієї функції не контролюється і може статися у будь-який довільний момент часу або взагалі ніколи.
Мал. 6.14. Функція без керування та входу
Блок із наявністю лише керування можна розглядати як виклик у програмі функції (процедури) без параметрів. Якщо блок має вхід, то він еквівалентний виклику в програмі функції з параметрами. Таким чином, блок без управління та входу еквівалентний функції, яка в програмі жодного разу не викликається на виконання.
На рис. 6.7–6.12, що відображають фрагменти діаграм IDEF0, зустрічаються блоки без входу та керування. Це не варто розглядати як помилку, тому що мається на увазі, що одна з цих стрілок має бути.
6. У кожного блоку має бути як мінімум один вихід.
Мал. 6.15. Функція без виходу
Роботи без результату не мають сенсу і не повинні моделюватись. Виняток становлять роботи, що відображаються у моделі AS-IS. Їх наявність свідчить про неефективність та недосконалість технологічних процесів. У моделі TO-BE ці роботи мають бути відсутніми.
7. При побудові діаграм слід мінімізувати кількість перетинів, петель та поворотів стрілок.
8. Зворотні зв'язки та ітерації (циклічні дії) можуть бути зображені за допомогою зворотних дуг. Зворотні зв'язки по входу малюються «нижньою» петлею, зворотний по управлінню – «верхній» (див. рис. 6.4 та 6.6).
9. Кожен блок та кожна стрілка на діаграмах повинні обов'язково мати ім'я. Дозволяється використовувати розгалуження (декомпозицію) або злиття (композицію) стрілок. Це пов'язано з тим, що ті самі дані або об'єкти, породжені однією роботою, можуть використовуватися відразу в кількох інших роботах. І навпаки, однакові чи однорідні дані та об'єкти, породжені різними роботами, можуть використовуватись в одному місці.
Мал. 6.16. Розгалуження стрілок
При цьому допускається завдання різним гілкам стрілки уточнюючих імен після розгалуження (до злиття). Якщо якась гілка після розгалуження не іменована, то вважається, що її ім'я відповідає імені стрілки, записаному до розгалуження.
Так, на рис. 6.16 управління, що входять до блоків «Виготовлення деталей» та «Складання виробу», мають уточнювальні значення та є складовоюнайбільш загального управління «Креслення». Для роботи блоку "Контроль якості" використовуються всі креслення.
На діаграмі не можна малювати стрілки, коли до і після розгалуження вони не іменовані. На рис. 6.17 стрілка, що входить до блоку «Формування типових відомостей», не має імені до та після розгалуження, що є помилкою.
Мал. 6.17. Неправильне найменування стрілок
10. При побудові діаграм для кращого читання може використовуватися механізм тунелювання стрілок. Наприклад, щоб не захаращувати зайвими деталями діаграми верхніх рівнів (батьківські), на діаграмах декомпозиції початок дуги поміщають у тунель.
Мал. 6.18. Тунелювання стрілок
У даному прикладі при побудові моделі проведення новорічного ранку механізм «дві сокири» не відображатиметься на діаграмах верхніх рівнів, при читанні яких може виникнути справедливе питання: «А навіщо потрібні дві сокири на новорічному ранку?».
Аналогічним чином можна виконувати тунелювання зі зворотною метою – недопущення відображення стрілки на діаграмах нижчих рівнів. У цьому випадку круглі дужки ставляться на кінці стрілки. На контекстній діаграмі (див. рис. 6.21) затунельовано механізм «Інженер служби колії», що входить до блоку «Визначення допустимих швидкостей». Таке рішення прийнято, оскільки інженер бере участь у всіх роботах, відображених на діаграмі декомпозиції цього блоку (див. рис. 6.22). Щоб не показувати цей зв'язок і не захаращувати діаграму декомпозиції, стрілку затунелювали.
11. Всі стрілки, що входять і виходять із блоку, при побудові для нього діаграми декомпозиції повинні бути відображені на ній. Виняток становлять затунельовані стрілки. Імена стрілок, перенесених на діаграму декомпозиції, мають збігатися з іменами, вказаними на діаграмі верхнього рівня.
12. Якщо дві стрілки проходять паралельно (починаються з однієї і тієї ж грані однієї роботи і закінчуються на одній і тій самій грані іншої роботи), то по можливості слід їх об'єднати і називати єдиним терміном.
Мал. 6.19. Об'єднання зв'язків
13. Кожен блок на діаграмах повинен мати власний номер. Для того, щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Блок на діаграмі верхнього рівня позначається 0, блоки на діаграмах другого рівня – цифрами від 1 до 9 (1, 2, …, 9), блоки на третьому рівні – двома цифрами, перша з яких вказує на номер блоку, що деталізується, з батьківської діаграми, а друга номер блоку по порядку на поточній діаграмі (11, 12, 25, 63) і т. д. А», за якою слідує номер декомпозованого блоку (наприклад, «А11», «А12», «А25», «А63»). На малюнку показано типове дерево діаграм (діаграма дерева вузлів) із нумерацією.
Мал. 6.20. Ієрархія діаграм
У сучасних CASE-засобах механізми нумерації робіт підтримуються автоматично. CASE-засоби забезпечують також автоматичну побудову діаграм дерева вузлів, які містять лише ієрархічні зв'язки. Вершиною такої діаграми може бути будь-який вузол (блок) і вона може бути побудована на будь-яку глибину.
6.6. Приклад побудови моделі IDEF0 для системи визначення допустимих швидкостей
Розрахунок допустимих швидкостей руху поїздів є трудомістким інженерним завданням. При проході поїздом будь-якої ділянки фактична швидкість руху поїзда не повинна перевищувати гранично допустиму. Ця гранично допустима швидкість встановлюється виходячи з досвіду експлуатації та спеціально проведених випробувань з динаміки руху та впливу на шлях рухомого складу. Неперевищення цієї швидкості гарантує безпеку руху поїздів, комфортабельні умови їзди пасажирів тощо. кривих, перехідних кривих, піднесення зовнішньої рейки тощо. буд.). Як правило, для встановлення допустимих швидкостей необхідно визначити не менше двох (на прямих) і п'яти (у кривих) швидкостей, з яких і вибирається остаточна допустима швидкість, як найменша з усіх розрахованих. Розрахунок цих швидкостей регламентуються Наказом МПС Росії № 41 від 12 листопада 2001 р. «Норми допустимих швидкостей руху рухомого складу по залізничним коліям колії 1520 (1524) мм Федерального залізничного транспорту».
Як було зазначено, побудова моделі IDEF0 починається з представлення всієї системи у вигляді найпростішої компоненти (контекстної діаграми). Дана діаграма відображає призначення (основну функцію) системи та необхідні вхідні та вихідні дані, керуючу та регламентуючу інформацію, а також механізми.
Контекстна діаграма для завдання визначення допустимих швидкостей показана на рис.6.21. Для побудови моделі використовувався продукт BPwin 4.0 компанії Computer Associates.
Мал. 6.21. Контекстна діаграма системи визначення допустимих швидкостей (методологія IDEF0)
В якості вихідної інформації, на основі якої виконується визначення допустимих швидкостей, використовуються:
Дані проекту нової лінії або проекту реконструкції (містять всю необхідну інформацію для реалізації проекту, а саме кілометраж, осі окремих пунктів, план лінії та ін.);
Детальний поздовжній профіль (містить інформацію, аналогічну до розглянутої вище);
Паспорт дистанції колії (містить інформацію, аналогічну до розглянутої вище, а також відомості про верхню будову колії (ВСП));
Дані про результати зйомки плану колії вагоном-шляховимірником;
Відомість піднесень зовнішньої рейки в кривих (містить інформацію про план шляху).
Частина вихідної інформації може бути взята з різних джерел. Зокрема, відомості про план (параметри кривих) можуть бути взяті з проекту нової лінії або проекту реконструкції, детального поздовжнього профілю, паспорта дистанції колії тощо.
Керуючими данимиє:
Вказівка начальника служби колії дороги або Департаменту колії та споруд ВАТ «РЗ» на розрахунок;
Наказ № 41, що містить нормативно-довідкову інформацію, порядок та формули визначення допустимих швидкостей;
Відомості про поточний або планований поїздопоток (дані про марки локомотивів, що обертаються, і типи вагонів, що використовуються);
Відомості про плановані ремонти шляху, реконструкцію та перебудову споруд та пристроїв.
Результатомроботи системи повинні бути:
Відомості допустимих швидкостей, що містять всі типи розрахованих швидкостей і дозволяють встановити причину їхнього обмеження;
Відомості Наказу начальника дороги про встановлення допустимих швидкостей на перегонах та окремих пунктах (Наказ «Н») згідно з прийнятою на дорозі формою. Затверджений Наказ «Н» офіційно закріплює допустимі швидкості руху поїздів;
Типові форми № 1, 1а і 2, що містять плановані швидкості, що допускаються для розробки графіка руху поїздів.
Швидкості, що містяться в Наказі «Н» і типових формах, можуть відрізнятися від розрахованих і показуваних у відомостях швидкостей, що допускаються. Це пов'язано з тим, що в них відображають обмеження швидкості не тільки за конструкцією рухомого складу, параметрів ВСП та кривих, але й за станом пристроїв та споруд (деформація земляного полотна, перекіс опор) контактної мережіі т.д.). Крім того, вони коригуються з урахуванням планованих ремонтів колії, реконструкції та перебудови споруд та пристроїв тощо.
Після побудови контекстна діаграма деталізується за допомогою діаграми декомпозиції першого рівня. На цій діаграмі відображаються функції системи, які мають бути реалізовані у межах основної функції. Діаграма, для якої виконана декомпозиція, по відношенню до деталізуючих її діаграм називається батьківської . Діаграма декомпозиції по відношенню до батьківської називається дочірньої .
Діаграма декомпозиції першого рівня для розглянутої задачі наведено на рис.6.22. Зазвичай, при побудові діаграми декомпозиції вихідна функція (декомпозируемая) розбивається на 3–8 підфункцій (блоків). При цьому блоки на діаграмі декомпозиції рекомендується розташовувати зліва направо зверху вниз, щоб краще було видно послідовність і логіка взаємодії підфункцій.
Мал. 6.22. Діаграма декомпозиції першого рівня (методологія IDEF0)
Черговість виконання функцій для розв'язання цієї задачі наступна:
Введення та коригування нормативно-довідкової інформації та даних по ділянках дороги (блоки 1 та 2);
Підготовка завдання для розрахунку (блок 3). У ньому вказується, для якої ділянки та колії, а також марки локомотива та типу вагонів слід виконати розрахунок;
Розрахунок допустимих швидкостей відповідно до порядку та формул, зазначених у Наказі № 41 (блок 4). В якості вихідної інформації виступають дані по шляху ділянки (план, верхня будова колії і т. д.) та нормативи, які обираються на підставі завдання на розрахунок;
Формування відомостей допустимих швидкостей (блок 5). На основі результатів розрахунку створюються кілька видів вихідних документів, які, з одного боку, дозволяють виявити причину обмежень швидкості, з іншого боку, виступають як основа для підготовки регламентованих документів;
Формування та підготовка проекту Наказу «Н» та типових відомостей (блоки 6 та 7).
Після побудови діаграми декомпозиції першого рівня для зазначених у ній функцій будуються окремі діаграми (діаграми декомпозиції другого рівня). Потім процес декомпозиції (побудови діаграм) триває до того часу, поки подальша деталізація функцій втрачає сенсу. Для кожної атомарної функції, що описує елементарну операцію (тобто функції, що не має діаграми декомпозиції), складається докладна специфікація, що визначає її особливості та алгоритм реалізації. Як доповнення до специфікації можна використовувати блок-схеми алгоритмів. Таким чином, процес функціонального моделювання полягає у поступовому вибудовуванні ієрархії функцій.
6.7. ICOM-коди
Стрілки, що входять в блок і виходять з нього на діаграмі верхнього рівня, є тими самими, що і стрілки, що входять в діаграму нижнього рівня і виходять з неї, тому що блок і діаграма представляють ту саму частину системи (див. рис. та ). Як наслідок цього, межі функції верхнього рівня – це те саме, що й межі діаграми декомпозиції.
ICOM-коди (Абревіатура від Input, Control, Output та Mechanism) призначені для ідентифікації граничних стрілок. ICOM-код містить префікс, що відповідає типу стрілки (I, С, Про або М), та порядковий номер (див. рис.).
- У складі моделі має бути контекстна діаграма A-0, яка містить тільки один блок. Номер єдиного блоку на контекстній діаграмі A-0 має бути 0.
- Блоки на діаграмі повинні розташовуватися по діагоналі – від верхнього лівого кута діаграми до правого нижнього в порядку привласнених номерів. Блоки на діаграмі, розташовані вгорі ліворуч, «домінують» над блоками, розташованими внизу праворуч. «Домінування» розуміється як вплив, який блок чинить інші блоки діаграми. Розташування блоків на аркуші діаграми відбиває авторське розуміння домінування. Таким чином, топологія діаграми показує, які функції мають більший вплив на інші.
- Неконтекстные діаграми мають містити щонайменше трьох і трохи більше шести блоків. Ці обмеження підтримують складність діаграм на рівні, доступному для читання, розуміння та використання. Діаграми з кількістю блоків менше трьох викликають серйозні сумніви щодо необхідності декомпозиції батьківської функції. Діаграми з кількістю блоків понад шість складні для сприйняття читачами і викликають у автора труднощі при внесенні до неї всіх необхідних графічних об'єктів та міток.
- Кожен блок неконтекстної діаграми отримує номер, що міститься у правому нижньому кутку; порядок нумерації - від верхнього лівого до нижнього правого блоку (номери від 1 до 6).
- Кожен блок, підданий декомпозиції, повинен мати посилання дочірню діаграму; посилання (наприклад, вузловий номер, номер C або номер сторінки) поміщається під правим нижнім кутом блоку.
- Імена блоків (функцій, що виконуються) і мітки стрілок повинні бути унікальними. Якщо мітки збігаються, це означає, що стрілки відображають тотожні дані.
- За наявності стрілок зі складною топологією доцільно повторити мітку для зручності її ідентифікації.
- Слід забезпечити максимальну відстань між блоками та поворотами стрілок, а також між блоками та перетинами стрілок для полегшення читання діаграми. Одночасно зменшується можливість переплутати дві різні стрілки.
- Блоки завжди повинні мати хоча б одну керуючу та одну вихідну стрілку, але можуть не мати вхідних стрілок.
- Якщо одні й самі дані служать керування, й у входу, викреслюється лише стрілка управління. Цим підкреслюється керуючий характер даних та зменшується складність діаграми.
- Максимально збільшена відстань між паралельними стрілками полегшує розміщення міток, їх читання та дозволяє простежити шляхи стрілок
- Стрілки зв'язуються (зливаються), якщо вони уявляють подібні
дані та їх джерело не вказано на діаграмі (рис. 2)
Малюнок 2 - Стрілки зв'язуються - Зворотні зв'язки з управління повинні бути показані як «вгору та над»
(Рис.3, а):
Малюнок 3 — Зворотні зв'язки Зворотні зв'язки по входу мають бути показані як «вниз та під» (рис. 3, б). Також показуються зворотні зв'язки з допомогою механізму. Таким чином забезпечується показ зворотного зв'язку за мінімальної кількості ліній і перетинів.
- Циклічні зворотні зв'язки для одного і того ж блоку зображуються лише для того, щоб їх виділити. Зазвичай зворотний зв'язок зображують на діаграмі декомпозирующей блок. Однак іноді потрібно виділити повторно використовувані об'єкти (рис. 4)
Рисунок 4 - Циклічні зворотні зв'язки - Стрілки об'єднуються, якщо вони мають спільне джерело або приймач, або вони являють собою пов'язані дані. Загальна назва найкраще описує суть даних. Слід мінімізувати число стрілок, що стосуються кожної сторони блоку, якщо, звісно, природа даних дуже різнорідна (рис. 5)
Рисунок 5 - Стрілки об'єднуються - Якщо можливо, стрілки приєднуються до блоків в одній позиції. Тоді з'єднання стрілок конкретного типу з блоками буде узгодженим і читання діаграми спроститься
Малюнок 6 - стрілки приєднуються до блоків в одній і тій же позиції - При з'єднанні великої кількості блоків необхідно уникати необов'язкових перетинів стрілок. Слід мінімізувати кількість петель та поворотів кожної стрілки
- Блоки (функції) є сполученими через середовище, якщо вони мають зв'язки з джерелом, що генерує дані, без конкретного визначення відношення окремої частини даних до якогось блоку
- Дві або більше функцій пов'язані через запис, якщо вони пов'язані з набором даних і не обов'язково залежать від того, чи представлені всі можливі інтерфейси як пару через середовище. Тип інтерфейсу, показаний на малюнку 10, кращий, оскільки визначаються відношення конкретних елементів даних до кожного блоку
- Необхідно використовувати (де це доцільно) виразні можливості стрілок, що гілкуються.
Навчіться бачити та розуміти функціональну структуру свого бізнесу!
В даний час в Росії різко зріс інтерес до загальноприйнятих на Заході стандартів менеджменту, однак, у реальній практиці управління існує один дуже показовий момент. Багатьох керівників досі можна поставити в безвихідь прямим питанням про організаційну структуру компанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, зазвичай, починають креслити зрозумілі лише їм одним ієрархічні діаграми, а й у процесі зазвичай швидко заходять у глухий кут. Те саме стосується співробітників і керівників різних службта функціональних підрозділів. У більшості випадків єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень та посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабо структуровані і невзаємопов'язані між собою і, внаслідок цього, просто припадають пилом на полицях. До певного часу подібний підхід був виправданий, оскільки під час становлення російської ринкової економіки поняття конкуренції практично не було, та й витрати вважати не було особливої необхідності - прибуток був гігантським. В результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, які виросли на початку 90-х років, поступово здають свої позиції, аж до повного виходу з ринку. Частково це зумовлено тим, що на підприємстві не було впроваджено стандарти управління, повністю не було поняття функціональної моделі діяльності та місії. За допомогою моделювання різних сфер діяльності можна досить ефективно аналізувати “вузькі місця” в управлінні та оптимізувати загальну схему бізнесу. Але, як відомо, на будь-якому підприємстві вищий пріоритет мають лише ті проекти, які безпосередньо приносять прибуток, тому про обстеження діяльності та її реорганізацію зазвичай йде лише під час відчутної кризи в управлінні компанією.
Наприкінці 90-х років, коли на ринку належною мірою з'явилася конкуренція та рентабельність діяльності підприємств почала різко падати, керівники відчули величезні складнощі при спробах оптимізувати витрати, щоб продукція залишалася одночасно і прибутковою та конкурентоспроможною. Саме в цей момент цілком чітко виявилася необхідність мати перед своїми очима модель діяльності підприємства, яка відображала б усі механізми та принципи взаємозв'язку різних підсистем у рамках одного бізнесу.
Саме ж поняття "моделювання бізнес-процесів" прийшло в побут більшості аналітиків одночасно з появою на ринку складних програмних продуктів, призначених для комплексної автоматизації управління підприємством. Подібні системи завжди мають на увазі проведення глибокого передпроектного обстеження діяльності компанії. Результатом цього обстеження є експертний висновок, у якому окремими пунктами виносяться рекомендації щодо усунення "вузьких місць" в управлінні діяльністю. На підставі цього висновку, безпосередньо перед проектом впровадження системи автоматизації, проводиться так звана реорганізація бізнес-процесів, іноді досить серйозна та болісна для компанії. Це і природно, колектив, що склався роками, завжди складно змусити "думати по-новому". Подібні комплексні обстеження підприємств завжди є складними і істотно відмінними час від часу завданнями. Для вирішення подібних завдань моделювання складних систем є добре обкатані методології та стандарти. До таких стандартів належать методологія сімейства IDEF. З їхньою допомогою можна ефективно відображати та аналізувати моделі діяльності широкого спектру складних систем у різних розрізах. При цьому широта та глибина обстеження процесів у системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними. На даний момент до сімейства IDEF можна віднести такі стандарти:
IDEF0 – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0, система, що вивчається, постає перед розробниками та аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків - у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи;
IDEF1 – методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати та аналізувати їх структуру та взаємозв'язки;
IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій "Сутність-взаємозв'язок" (ER - Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до системи, що розглядається;
IDEF2 – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на початковому етапі. Однак у час присутні алгоритми та його комп'ютерні реалізації, дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані з урахуванням “розфарбованих мереж Петри” (CPN – Color Petri Nets);
IDEF3 – методологія документування процесів, які у системі, яка використовується, наприклад, для дослідження технологічних процесів на підприємствах. За допомогою IDEF3 описуються сценарій та послідовність операцій для кожного процесу. IDEF3 має прямий взаємозв'язок із методологією IDEF0 – кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;
IDEF4 - методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів та закладені принципи їхньої взаємодії, тим самим дозволяючи аналізувати та оптимізувати складні об'єктно-орієнтовані системи;
IDEF5 – методологія онтологічного дослідження складних систем. За допомогою методології IDEF5 онтологія системи може бути описана за допомогою певного словника термінів і правил, на підставі яких можуть бути сформовані достовірні твердження про стан системи, що розглядається в певний момент часу. На основі цих тверджень формуються висновки щодо подальшого розвитку системи та проводиться її оптимізація.
У рамках цієї статті ми розглянемо методологію функціонального моделювання IDEF0, що найчастіше використовується.
Історія виникнення стандарту IDEF0
Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). Кілька років тому у Росії невеликим тиражем вийшла однойменна книга, присвячена опису основних принципів побудови SADT-діаграм. Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, яка мала позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Власне сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF = ICAM DEFinition). У процесі практичної реалізації учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії у промислових системах. При цьому, крім удосконаленого набору функцій для опису бізнес-процесів, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках “аналітик-фахівець”. Іншими словами, новий методповинен був забезпечити групову роботу над створенням моделі, за участю всіх аналітиків і фахівців, зайнятих у рамках проекту.
Через війну пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. З 1981 року стандарт IDEF0 зазнав кілька незначних змін, в основному обмежуючого характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом Стандарів і Технологій США (NIST).
Основні елементи та поняття IDEF0
Графічна мова IDEF0 напрочуд проста і гармонійна. В основі методології лежать чотири основні поняття.
Першим є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (див. рис. 1) і уособлює деяку конкретну функцію в рамках аналізованої системи. За вимогами стандарту назва кожного функціонального блоку має бути сформульована у дієслівному способі (наприклад, “здійснювати послуги”, а не “виробництво послуг”).
Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:
Кожен функціональний блок у рамках єдиної системи, що розглядається, повинен мати свій унікальний ідентифікаційний номер.
1. Функціональний блок.
Другим "китом" методології IDEF0 є поняття інтерфейсної дуги (Arrow). Також інтерфейсні дуги часто називають потоками чи стрілками. Інтерфейсна дуга відображає елемент системи, який обробляється функціональним блоком або впливає на функцію, відображену цим функціональним блоком.
Графічним відображенням інтерфейсної дуги є спрямована односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування має бути оборотом іменника.
За допомогою інтерфейсних дуг відображають різні об'єкти, що в тій чи іншій мірі визначають процеси, що відбуваються в системі. Такими об'єктами можуть бути елементи реального світу (деталі, вагони, співробітники тощо) або потоки даних та інформації (документи, дані, інструкції тощо).
Залежно від того, до якої зі сторін підходить дана інтерфейсна дуга, вона називається "вхідною", "вихідною" або "керуючою". Крім того, "джерелом" (початком) і "приймачем" (кінцем) кожної функціональної дуги можуть бути тільки функціональні блоки, при цьому "джерелом" може бути тільки вихідна сторона блоку, а "приймачем" будь-яка з трьох, що залишилися.
Необхідно відзначити, що будь-який функціональний блок за вимогами стандарту повинен мати принаймні одну інтерфейсну дугу, що управляє, і одну вихідну. Це і зрозуміло - кожен процес повинен відбуватися за якимись правилами (відображається керуючою дугою) і повинен видавати деякий результат (дуга, що виходить), інакше його розгляд не має ніякого сенсу.
При побудові IDEF0 - діаграм важливо правильно відокремлювати вхідні інтерфейсні дуги від керуючих, що часто буває непросто. Наприклад, малюнку 2 зображено функціональний блок “Обробити заготівлю”.
У реальному процесі робочому, що робить обробку, видають заготівлю та технологічні вказівки з обробки (або правила техніки безпеки при роботі зі верстатом). Помилково може здатися, що й заготівля та документ із технологічними вказівками є вхідними об'єктами, проте це не так. Насправді в цьому процесі заготівля обробляється за правилами, відображеними в технологічних вказівках, які повинні відповідно зображуватися керуючою інтерфейсною дугою.
Малюнок 2.
Інша річ, коли технологічні вказівки обробляються головним технологом і до них вносяться зміни (рис. 3). У цьому випадку вони відображаються вже вхідною інтерфейсною дугою, а об'єктом, що управляє, є, наприклад, нові промислові стандарти, виходячи з яких проводяться дані зміни.
Малюнок 3.
Наведені вище приклади підкреслюють зовні схожу природу вхідних і інтерфейсних дуг, що управляють, проте для систем одного класу завжди є певні розмежування. Наприклад, у разі розгляду підприємств та організацій існують п'ять основних видів об'єктів: матеріальні потоки (деталі, товари, сировина тощо), фінансові потоки (готівкові та безготівкові, інвестиції тощо), потоки документів (комерційні, фінансові та організаційні документи), потоки інформації (інформація, дані про наміри, усні розпорядження тощо) та ресурси (співробітники, верстати, машини тощо). При цьому в різних випадках вхідними та вихідними інтерфейсними дугами можуть відображатися всі види об'єктів, що керують лише що стосуються потоків документів та інформації, а дугами-механізмами лише ресурси.
Обов'язкова наявність управляючих інтерфейсних дуг одна із головних відмінностей стандарту 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. Слід звернути увагу до взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра у нижньому правому куті прямокутника), а позначення під правим кутом вказує на номер дочірньої при цьому блоку діаграми . Відсутність цього позначення свідчить, що декомпозиції для цього блоку немає.
Часто бувають випадки, коли окремі інтерфейсні дуги не мають сенсу продовжувати розглядати в дочірніх діаграмах нижче за якийсь певний рівень в ієрархії, або навпаки - окремі дуги не мають практичного сенсу вище за якийсь рівень. Наприклад, інтерфейсну дугу, що зображує "деталь" на вході в функціональний блок "Обробити на токарному верстаті" не має сенсу відбивати на діаграмах більше високих рівнів– це буде лише перевантажувати діаграми та робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися окремих "концептуальних" інтерфейсних дуг і не деталізувати їх глибше за певний рівень. Для вирішення таких завдань у стандарті IDEF0 передбачено поняття тунелювання. Позначення "тунелю" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги означає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася (з "тунелю") тільки на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близько від блоку - приймача означає той факт, що в дочірній по відношенню до цього блоку діаграмі ця дуга відображатися і не розглядатиметься. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії – у такому разі вони спочатку “занурюються в тунель”, а потім, за необхідності, “повертаються з тунелю”.
Останнім із понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення та підтримку набору відповідних визначень, ключових слів, оповідальних викладів тощо, які характеризують об'єкт, відображений цим елементом. Цей набір називається глосарієм та є описом сутності даного елемента. Наприклад, для керуючої інтерфейсної дуги "розпорядження про оплату" глосарій може містити перелік полів відповідного дуги документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочну графічну мову, забезпечуючи діаграми необхідною додатковою інформацією.
4. Декомпозиція функціональних блоків.
Принципи обмеження складності IDEF0-діаграм
Зазвичай IDEF0-моделі несуть у собі складну та концентровану інформацію, і для того, щоб обмежити їх перевантаженість і зробити легкочитаними, у відповідному стандарті прийнято відповідні обмеження складності:
Обмеження кількості функціональних блоків на діаграмі трьома-шістьма. Верхня межа (шість) змушує розробника використовувати ієрархії при описі складних предметів, а нижня межа (три) гарантує, що на відповідній діаграмі достатньо деталей, щоб виправдати її створення;
Обмеження кількості підходять до одного функціонального блоку (що виходять із одного функціонального блоку) інтерфейсних дуг чотирма.
Зрозуміло, суворо дотримуватися цих обмежень зовсім необов'язково, проте, як свідчить досвід, є дуже практичними у реальній роботі.
Дисципліна групової роботи над розробкою IDEF0-моделі
Стандарт IDEF0 містить набір процедур, що дозволяють розробляти і узгоджувати модель великою групою людей, що належать до різних областей діяльності системи, що моделюється. Зазвичай процес розробки є ітеративним і складається з наступних умовних етапів:
Створення моделі групою фахівців, які належать до різних сфер діяльності підприємства. Ця група у термінах IDEF0 називається авторами (Authors). Побудова початкової моделі є динамічним процесом, протягом якого автори опитують компетентних осіб структуру різних процесів. На основі наявних положень, документів та результатів опитувань створюється чернетка (Model Draft) моделі.
Поширення чернетки для розгляду, погоджень та коментарів. На цій стадії відбувається обговорення чернетки моделі з широким спектром компетентних осіб (у термінах IDEF0-читачів) на підприємстві. При цьому кожна з діаграм чорнової моделі письмово критикується та коментується, а потім передається автору. Автор, у свою чергу, також письмово погоджується з критикою або відкидає її з викладом логіки прийняття рішення і знову повертає відкориговану чернетку для подальшого розгляду. Цей цикл триває доти, доки автори та читачі не дійдуть єдиної думки.
Офіційне утвердження моделі. Твердження узгодженої моделі відбувається керівником робочої групи в тому випадку, якщо у авторів моделі та читачів відсутні розбіжності щодо її адекватності. Остаточна модель є узгоджене уявлення про підприємство (систему) із заданої точки зору та для заданої мети.
Наочність графічної мови IDEF0 робить модель цілком читаною для осіб, які не брали участі в проекті її створення, а також ефективною для проведення показів та презентацій. Надалі, з урахуванням побудованої моделі можуть бути організовані нові проекти, націлені виробництва змін на підприємстві (у системі).
Особливості національної практики застосування функціонального моделювання засобами IDEF0
В останні роки інтерес у Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної веб-сторінки (http://www.vernikov.ru), де коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5, я б назвав теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне, перші Case-засоби, що дозволяють будувати DFD і IDEF0 діаграми з'явилися на російському ринку ще в 1996 році, одночасно з виходом популярної книги за принципами моделювання в стандартах SADT.
Тим не менш, більшість керівників досі розцінюють практичне застосування моделювання в стандартах IDEF швидше як данина моді, ніж ефективний шлях оптимізації існуючої системи управління бізнесом. Найімовірніше це пов'язано з яскраво вираженим недоліком інформації щодо практичного застосування цих методологій та з неодмінним софтверним ухилом абсолютної більшості публікацій.
Не секрет, що практично всі проекти обстеження та аналізу фінансової та господарської діяльності підприємств зараз у Росії так чи інакше пов'язані з побудовою автоматизованих систем управління. Завдяки цьому стандарти IDEF у розумінні більшості стали умовно невіддільні від впровадження. інформаційних технологій, хоча з допомогою часом можна ефективно вирішувати навіть невеликі локальні завдання, буквально з допомогою олівця і бумаги.
При проведенні складних проектів обстеження підприємств розробка моделей у стандарті IDEF0 дозволяє наочно та ефективно відобразити весь механізм діяльності підприємства у потрібному розрізі. Однак найголовніше – це можливість колективної роботи, яку надає IDEF0. У моїй практичній діяльності було досить багато випадків, коли побудова моделі здійснювалася з прямою допомогою співробітників різних підрозділів. При цьому консультант за досить короткий час пояснював їм основні принципи IDEF0 та навчав роботі з відповідним прикладним. програмним забезпеченням. В результаті співробітники різних відділів створювали IDEF-діаграми діяльності свого функціонального підрозділу, які повинні були відповісти на такі питання:
Що надходить у підрозділ "на вході"?
Які функції і в якій послідовності виконуються в рамках підрозділу?
Хто відповідальний за виконання кожної з функцій?
Чим керується виконавець під час виконання кожної з функцій?
Що результат роботи підрозділу (на виході)?
Після узгодження чернеток діаграм усередині кожного конкретного підрозділу, вони збираються консультантом у чорнову модель підприємства, в якій ув'язуються всі вхідні та вихідні елементи. На цьому етапі фіксуються всі проблеми окремих діаграм та його спірні місця. Далі, ця модель знову проходить через функціональні відділи для подальшого узгодження та внесення необхідних коректив. В результаті, за досить короткий час і при залученні мінімуму людських ресурсів з боку консультаційної компанії (а ці ресурси, як відомо, дуже недешеві), виходить IDEF0-модель підприємства за принципом "Як є", причому, що важливо, вона представляє підприємство з позиції співробітників, які у ньому працюють та досконало знають усі нюанси, у тому числі неформальні. Надалі ця модель буде передана на аналіз та обробку до бізнес-аналітик, які займатимуться пошуком “вузьких місць” в управлінні компанією та оптимізацією основних процесів, трансформуючи модель “Як є” у відповідне уявлення “Як має бути”. На підставі цих змін і виноситься підсумковий висновок, який містить у собі рекомендації щодо реорганізації системи управління.
Зрозуміло, подібний підхід потребує низки організаційних заходів, насамперед із боку керівництва обстежуваного підприємства. Це зумовлено тим, що ця техніка передбачає покладання деяких співробітників додаткових обов'язків з освоєння і практичного застосування нових методологій. Однак у кінцевому підсумку це виправдовує себе, оскільки додаткові одну-дві години роботи окремих співробітників протягом кількох днів дозволяють суттєво економити кошти на оплату консультаційних послуг сторонньої компанії (які у будь-якому випадку будуть відривати від роботи тих самих працівників анкетами та питаннями). Щодо самих працівників підприємства, так чи інакше вираженої протидії з їхнього боку я у своїй практиці не зустрічав.
Висновок з усього цього можна зробити наступний: зовсім не обов'язково щоразу самим вигадувати рішення для стандартних завдань. Завжди, коли ви стикаєтеся з необхідністю аналізу тієї чи іншої функціональної системи (від системи проектування космічного корабля, до процесу приготування комплексної вечері) – використовуйте роками перевірені та обкатані методи. Одним з таких методів і є IDEF0, що дозволяє за допомогою свого простого та зрозумілого інструментарію вирішувати складні життєві завдання.
Основний із трьох методологій, що підтримуються BPwin, є IDEF0. IDEF0 відноситься до сімейства IDEF, яке з'явилося в кінці шістдесятих років під назвою SADT (Structured Analysis and Design Technique). IDEF0 можна використовувати для моделювання широкого класу систем. Для нових систем застосування IDEF0 має на меті визначення вимог та вказівку функцій для подальшої розробки системи, що відповідає поставленим вимогам та реалізує виділені функції. Стосовно вже існуючих систем IDEF0 може бути використана для аналізу функцій, що виконуються системою та відображення механізмів, за допомогою яких ці функції виконуються. Результатом застосування IDEF0 до деякої системи є модель цієї системи, що складається з ієрархічно впорядкованого набору діаграм, тексту документації та словників, пов'язаних один з одним за допомогою перехресних посилань. Двома найбільш важливими компонентами, з яких будуються діаграми IDEF0, є бізнес-функції або роботи (представлені на діаграмах у вигляді прямокутників) та дані та об'єкти (зображувані у вигляді стрілок), що зв'язують між собою роботи. При цьому стрілки, залежно від того, в яку грань прямокутника роботи вони входять або з якої грані виходять, діляться на п'ять видів:
Стрілки входу (входять у ліву грань роботи) - зображують дані чи об'єкти, змінювані під час виконання роботи.
Стрілки управління (входять у верхню межу роботи) - зображують правила та обмеження, згідно з якими виконується робота.
Стрілки виходу (виходять із правої межі роботи) - зображують дані чи об'єкти, які у результаті виконання роботи.
Стрілки механізму (входять у нижню грань роботи) - зображують ресурси, необхідних виконання роботи, але які змінюються у процесі роботи (наприклад, устаткування, людські ресурси…)
Стрілки виклику (виходять із нижньої межі роботи) - зображають зв'язки між різними діаграмами або моделями, вказуючи на деяку діаграму, де дана роботарозглянута докладніше.
Усі роботи та стрілки мають бути іменовані. Перша діаграма в ієрархії діаграм IDEF0 завжди зображує функціонування системи загалом. Такі діаграми називають контекстними. У контекст входить опис мети моделювання, області (описи того, що розглядатиметься як компонент системи, а що як зовнішній вплив) і погляду (позиції, з якою будуватися модель). Зазвичай як точки зору вибирається точка зору особи або об'єкта, відповідального за роботу системи, що моделюється в цілому.
Малюнок 7.1. Функціональний блок та інтерфейсні дуги
Роботи на діаграмах зображуються як прямокутників (функціональні блоки). Кожна робота зображує будь-яку функцію або завдання і називається дієсловом або дієслівною фразою, що позначає дію, наприклад Виготовлення виробу, Обслуговування клієнта і т.д. Стрілки позначаються іменником і позначають об'єкти або інформацію, що пов'язує роботи між собою та із зовнішнім світом.
Після опису контексту проводиться функціональна декомпозиція-система розбивається на підсистеми кожна підсистема описується у тому синтаксисі, як і система загалом. Потім кожна підсистема розбивається більш дрібні і до досягнення потрібного рівня подробиці. В результаті такого розбиття кожен фрагмент системи зображується на окремій діаграмі декомпозиції.
Після того, як контекст описаний, проводиться побудова наступних діаграм в ієрархії. Кожна наступна діаграма є більш докладним описом(декомпозицією) однією з робіт на вищій діаграмі. Приклад декомпозиції контекстної роботи показано на Рис.7.2 та Рис.7.4. Опис кожної підсистеми проводиться аналітиком разом із експертом предметної області. Зазвичай експертом є людина, яка відповідає за цю підсистему і тому досконало знає всі її функції. Таким чином, вся система розбивається на підсистеми до потрібного рівня деталізації, і виходить модель, що апроксимує систему із заданим рівнем точності. Отримавши модель, що адекватно відображає поточні бізнес-процеси (так звану модель AS IS), аналітик з легкістю може побачити всі найвразливіші місця системи. Після цього з урахуванням виявлених недоліків можна будувати модель нової організації бізнес-процесів (модель TO BE).
Однією з найважливіших особливостей методології SADT є поступове запровадження дедалі більших рівнів деталізації у міру створення діаграм, що відображають модель.
На малюнку 7.2, де наведено три діаграми та їх взаємозв'язку, показано структуру IDEF0.-моделі. Кожен компонент моделі може бути декомпозований інший діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі.
Рисунок 7.2 – Приклад контекстної діаграми
Як видно на Рис.7.2, BPwin дозволяє виділяти роботи та стрілки різними кольорами, а також прив'язувати імена стрілок до самих стрілок (стрілка на ім'я Звітність), що підвищує наочність і читаність діаграми.
Рисунок 7.3 – Приклад діаграми декомпозиції
Малюнок7 . 4 - Приклад контекстної діаграми
Малюнок 7.5 -Приклад діаграми декомпозиції
Ієрархія діаграм
Побудова IDEF0-моделі починається з представлення всієї системи у вигляді найпростішої компоненти - одного блоку та дуг, що зображають інтерфейси з функціями поза системою. Оскільки єдиний блок представляє всю систему як єдине ціле, ім'я, вказане у блоці, є спільним. Це вірно і для інтерфейсних дуг - вони також являють собою повний набір зовнішніх інтерфейсів системи в цілому.
Потім блок, який представляє систему як єдиний модуль, деталізується на іншій діаграмі за допомогою декількох блоків, з'єднаних інтерфейсними дугами. Ці блоки є основними підфункціями вихідної функції. Ця декомпозиція виявляє повний набір підфункцій, кожна з яких представлена як блок, межі якого визначені інтерфейсними дугами. Кожна з цих підфункцій може бути декомпозована подібним чином для детальнішого подання.
У всіх випадках кожна підфункція може містити лише ті елементи, які входять до вихідної функції. Крім того, модель не може опустити будь-які елементи, тобто, як зазначалося, батьківський блок і його інтерфейси забезпечують контекст. До нього не можна нічого додати, і з нього не може бути видалено нічого.
Дуги, що входять у блок і що виходять з нього на діаграмі верхнього рівня, є точно тими самими, що і дуги, що входять в діаграму нижнього рівня і що виходять з неї, тому що блок і діаграма представляють одну і ту ж частину системи.
Малюнок 7.6 – Структура SADT-моделі. Декомпозиція діаграм
Малюнок 7.7 - Відповідність має бути повною та несуперечливою
Деякі дуги приєднані до блоків діаграми обома кінцями, в інших один кінець залишається неприєднаним. Неприєднані дуги відповідають входам, керуванням та виходам батьківського блоку. Джерело або одержувач цих прикордонних дуг може бути знайдено лише на батьківській діаграмі. Неприєднані кінці повинні відповідати дугам на вихідній діаграмі. Всі граничні дуги повинні продовжуватися на батьківській діаграмі, щоб вона була повною та несуперечливою.
Як було зазначено, механізми (дуги з нижньої сторони) показують засоби, за допомогою яких здійснюється виконання функцій. Механізм може бути людиною, комп'ютером або будь-яким іншим пристроєм, який допомагає виконувати цю функцію (рис. 7.8).
Мал. 7.8. Приклад механізму
Кожен блок на діаграмі має власний номер. Блок будь-якої діаграми може бути описаний далі діаграмою нижнього рівня, яка, в свою чергу, може бути далі деталізована за допомогою необхідного числа діаграм. Отже, формується ієрархія діаграм.
Щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є верхньою діаграмою моделі. На малюнку 7.9 показано типове дерево діаграм.
Рисунок 7.9 – Ієрархія діаграм
Лекція 8. МетодологіяDFDіIDEF3
