Програми розробки моделей idef0. Методологія IDEF0

IDEF0 діаграми будуються за допомогою програми BPWin. Призначені вони для графічного моделювання бізнес-процесів, що відбуваються.

Про методологію IDEF0

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

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

Елементи, що використовуються для IDEF0

Як уже згадувалося, використовується 2 типи геометричних примітивів: прямокутники та стрілки. Прямокутники позначають певні процеси, функції, роботи чи завдання, що мають цілі та ведуть до зазначеного результату. Взаємодія процесів між собою та зовнішнім середовищем позначається за допомогою стрілок. У IDEF0 розрізняють 5 різних типів стрілок.

Можливості використання IDEF0

Методологію IDEF0 можна використовуватиме опису функціонального аспекту будь-якої інформаційної системи.

Типи зв'язків між процесами IDEF0

В інтересах моделі створювати такі зв'язки побудов, щоб внутрішні зв'язки були якомога сильнішими, а зовнішні - якомога слабшими. Це сильний бік моделювання за допомогою IDEF0. Приклади діаграм ви можете побачити самі та переконатися у правдивості цих слів. Для полегшення встановлення зв'язків такі з'єднуються у модулі. Між модулями встановлюються зовнішні зв'язки, а всередині модулів – внутрішні. Розрізняють кілька типів зв'язків.

1. Ієрархічний («частина» - «ціле») зв'язок.

2. Керуюча (регламентуюча, підлегла):

2) зворотний зв'язок управління.

3. Функціональна чи технологічна:

2) зворотний вхідний.

3) споживча;

4) логічна;

5) методична чи колегіальна;

6) ресурсна;

7) інформаційна;

8) тимчасова;

9) випадкова.

Побудова блоків та зв'язків у діаграмах

Методологія IDEF0 надає цілий ряд правил та рекомендацій щодо свого використання та покращення якості використання. Так, у діаграмі відображається один блок, на якому можна задати назву системи, її призначення. До блоку або блоку веде 2-5 стрілок. Можна більше або менше, але щонайменше дві стрілки необхідні для входу/виходу, а решта для додаткових робіт та їх вказівки на діаграмі. Якщо стрілок більше 5, слід подумати про оптимальність побудови моделі, і чи не можна зробити її ще більш деталізованою.

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

Кількість блоків, яка буде на одній діаграмі, рекомендована в кількості 3-6. Якщо їх менше, то такі діаграми навряд чи нестимуть смислове навантаження. Якщо кількість блоків буде величезною, то прочитати таку діаграму буде дуже складно, враховуючи наявність ще й додаткових стрілок. Для покращення сприйняття інформації розміщувати блоки рекомендується зверху донизу та зліва направо. Таке розташування дозволить відобразити логіку виконання послідовності процесів. А також стрілки створюватимуть меншу плутанину, володіючи мінімальною кількістю перетинів один з одним.

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

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

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

Найменування

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

Часто використовується злиття стрілок, і постають питання про їх назву. Але злиття можливе лише у разі передачі однорідних даних, тому окремі імена не потрібні, хоча у програмі BPWin їх можна задати. Також, якщо відбувається розбіжність стрілок, їх можна окремо найменувати, щоб розуміти, що відповідає.

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

Інформація про стрілки

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

Приклад реалізації методології IDEF0 на конкретній моделі

Ви вже дізналися, що таке IDEF0 діаграма, приклади та правила побудови таких діаграм частково побачили. Тепер слід звернутись і до практики. Для кращого розуміння пояснення йтиме не на якійсь «загальній» моделі, а на конкретному прикладі, який дозволить краще та повніше зрозуміти особливості роботи з IDEF0 у програмі BPWin.

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

Вихідною інформацією виступають:

1. дані про лінію шляхів;
2. паспорт усієї дистанції;
3. план шляху.

Керуючі дані:

1. Вказівка ​​начальника, завідувача служби шляхів.
2. Відомості про існуючий потік пересування поїздів.
3. Відомості про заплановані ремонти, реконструкції та зміну шляхів.

Результатом моделі є:

1. Обмеження допустимих швидкостей із зазначенням причини обмеження.
2. Допустимі швидкості при русі на окремих пунктах і під час перегону поїздів.

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

Висновок

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

Мета роботи:

• вивчення основних принципів методології IDEF0,
• створення нового проекту в BPWin,
• формування контекстної діаграми,
• проведення зв'язків.

Опис системи за допомогою 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

При запуску 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не змінює свого значення, отже, збалансованість діаграми змінюється.

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

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

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

перелік Контрольних питань:

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

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

Мал. 3.12

Побудова моделей

Жодна Модельне повинна будуватися без ясного усвідомлення об'єкта та цілей моделювання. При виборі мети моделювання необхідно відповісти на такі запитання:

• Чому моделюється цей процес?
• Що виявить дана модель?
• Як ті, хто ознайомиться з цією моделлю, зможуть її застосувати?

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

• Які завдання менеджера?
• Які завдання клерка?
• Хто контролює роботу?
• Яка технологія необхідна виконання кожного кроку тощо.

Точка зору

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

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

Межі моделювання

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

Межі моделюваннямають два компоненти: ширину охоплення та глибину деталізації. Ширина охоплення позначає зовнішні межі моделі, що моделюється. Глибина деталізації визначає ступінь подробиці, з якою необхідно проводити декомпозицію багатофункціональних блоків.

Щоб полегшити правильне визначення меж моделюванняпри розробці IDEFO-моделей суттєві зусилля витрачаються на розробку та рецензування контекстної діаграми IDEFO (діаграми "найвищого" рівня). Іноді навіть вдаються до побудови додаткової діаграми для відображення рівня вищого, ніж контекстний для даної моделі, що дозволяє визначити систему, всередині якої розташовується об'єкт для моделювання. Істотні витрати на розробку контекстної діаграми цілком виправдані, оскільки вона є свого роду "точкою відліку" для інших діаграм моделі, і внесені до неї зміни каскадом відбиваються на всі рівні, що лежать нижче.

Коли межі моделюваннязрозумілі, також стає зрозумілим, які об'єкти системи з тих чи інших причин не увійшли до моделі.

Вибір найменування контекстного блоку

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

Правила підбору імені для контекстного блоку загалом не відрізняються від загальних правил іменування функціональних блоківтому для них зазвичай підбирають узагальнюючі назви типу "Управління відділом по роботі з клієнтами", "Обробка замовлень" і т.п.

Визначення стрілок на контекстній діаграмі

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

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

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

Визначеннямеханізмів виконання. Після створення входів і виходів можна розпочати розгляд механізмів виконання або ресурсів, що належать до функціонального блоку. До поняття механізму виконання входять персонал, обладнання, інформаційні системи тощо. Наприклад, функціональний блок "Зібрати деталь" може вимагати використання будь-якого обладнання, наприклад, гайкового ключа. При прийомі іспитів на права водія механізмом виконання є інспектор ДІБДР. Як правило, визначити механізм виконання для функціональних блоків досить просто.

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

Коли контекстна діаграма є завершеною, спробуйте поставити такі питання:

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

Нумерація блоків та діаграм

Усі функціональні блоки IDEF0 нумеруються. У номерах допускається використання префіксів довільної довжини, але у переважній більшості моделей використовується префікс А. Номер блокупроставляється за префіксом. Контекстний блок має номер АТ.

Префікс повторюється кожного блоку моделі. Номеривикористовуються для відображення рівня декомпозиції, на якому знаходиться блок. Блок АТ декомпозується блоки Al, A2, A3 і т.д.; блок А1 - А11, А12, А13 і т.д.; блок - А11 А111, А112, А113 і т.д. Для кожного рівня декомпозиції наприкінці номера додається одна цифра.

Два підходи до початку моделювання

Моделі можуть проектуватися як із використанням підходу"в ширину", коли кожна діаграма максимально деталізується перед своєю декомпозицією, так і з підходом "в глибину", коли спочатку визначається ієрархія блоків, а потім створюються стрілки, що їх з'єднують. Природно, можливе застосування цих комбінацій підходів, причому ієрархія блоків може іноді трохи змінюватись після того, як намальовані стрілки. Це відбувається у випадку, коли створення стрілок може змінити розуміння внутрішньої архітектури об'єкта, що моделюється.

Коли зупинитися

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

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

Інші діаграми IDEF0

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

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

Презентаційні діаграми. Презентаційні діаграми (For Exposition Only diagrams - FEO diagrams) часто включають моделі, щоб проілюструвати інші погляду чи деталі, які виходять поза рамки традиційного синтаксису IDEF0. Діаграми FEO допускають порушення будь-яких правил побудови діаграм IDEF0з метою виділення важливих з погляду аналітика елементів моделі. Природно, якщо діаграма FEO включена в модель виключно для відображення іншої точки зору на систему, вона, швидше за все, виглядатиме зовні як звичайна IDEF0-діаграма, задовольняючи всі обмеження IDEF0.

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

Крім того, зустрічаються такі види презентаційних діаграм:

• копія IDEF0-діаграми, яка містить всі функціональні блоки та стрілки, що відносяться тільки до одного з функціональних блоків, - це дозволяє відобразити взаємодію між цим блоком та іншими об'єктами діаграми;

• копія IDEF0-діаграми, яка містить всі функціональні блоки та стрілки, що безпосередньо відносяться тільки до входу та/або виходу батьківського блоку;
• Різні точки зору, як правило, на глибину одного рівня декомпозиції.

IDEF0 методи є внесені до моделі функцій процесу, створюючи графічний model, що відображають: які керують функцією, які роблять це, які ресурси будуть використані і як вони connected with інші функції. The IDEF0 інструмент використовується для моделі рішень, дій, і діяльності з системою системи при розробці процесів . IDEF0 diagram graphically depicts як model of desired version of the application. Концепція Draw PRO дозволяє вам створити і комунікувати IDEF0 diagrams of any complexity.

Підходом, заснованим на методології загального опису та функціонального моделювання бізнес-процесів, є методологія IDEF0. В її основі лежить методологія інтегрованого комп'ютеризованого виробництва (Integrated Computer-Aided Manufacturing - ICAM), що використовувалася у військово-повітряних аерокосмічних лабораторіях США в процесі розробки та створення нових видів літаків і космічних апаратів. Пізніше на цій основі було розроблено та введено в дію в 1993 р. федеральний стандарт США з інформаційних технологій - Публікація? 183 (Federal Information Processing Standard, Publication 183).

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

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

Основу графічної мови IDEF0, синтаксис і семантика якої визначені з абсолютною строгістю, складають блоки і стрілки, що з'єднують їх, які формують ієрархію деталізованих діаграм.

Малюнок 1. Ієрархія деталізованих діаграм IDEF0.

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

Стрілки можуть бути чотирьох видів:

Малюнок 2. Позиціонування стрілок моделі IDEF0.

• Входи ( Input ) та Виходи ( Output ) (підходять ліворуч до блоків і виходять праворуч від них) - являють собою дані, об'єкти, матеріали тощо, що відносяться до функцій, що виконуються блоками (це, як правило, перероблені ресурси і результати виконання окремих функцій блоків);
• Механізми виконання функцій ( Механізм ) (підходять знизу до блоків) - є довгострокові ресурси, необхідні для виконання відповідних робіт (це можуть бути конкретні працівники, підрозділи організації, машини, обладнання, комп'ютерна техніка тощо);
• Управління чи регламентуючі документи ( Control ) (Підходять зверху до блоків) − являють собою умови, директиви, керівні документи тощо, що керують виконанням цієї функції.

Компоненти синтаксису IDEF0- блоки, стрілки, діаграми та правила.

Блоки являють собою функції, що визначаються як діяльність, процес, операція, дія або перетворення.
Стрілки представляють дані чи матеріальні об'єкти, пов'язані з функціями.
Правила визначають, як застосовувати компоненти; діаграми забезпечують формат графічного та словесного опису моделей. Формат утворює основу управління конфігурацією моделі.

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

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

Малюнок 3. Стрілки на IDEF0-діаграмі.

Для блоківвстановлені наступні синтаксичні правила:

• розміри блоків повинні бути достатніми для того, щоб включити ім'я та номер блоку;
• блоки мають бути прямокутними, з прямими кутами;
• блоки мають бути намальовані суцільними лініями.

Для стрілоквстановлені наступні синтаксичні правила:

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

IDEF0-моделі складаються з документівтрьох типів:

• графічних діаграм,
• тексту
• глосарія.

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

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

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

Кожна модель повинна мати контекстну діаграму верхнього рівня, де об'єкт моделювання представлений єдиним блоком з граничними стрілками. Ця діаграма називається А-0 (А мінус нуль). Стрілки на цій діаграмі відображають зв'язки об'єкта моделювання з довкіллям. Оскільки єдиний блок представляє весь об'єкт, його ім'я – спільне для проекту. Це справедливо і всім стрілок діаграми, оскільки вони представляють повний комплект зовнішніх інтерфейсів об'єкта. Діаграма А-0 встановлює область моделювання та її межу.

4. Приклад контекстної діаграми верхнього рівня.

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

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

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

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