Лабораторна робота Розробка моделі бізнес-процесу в нотації IDEF3

Мета: Набути знань і практичних навичок розробки діаграми бізнес-процесу в нотації IDEF3 і усвідомити мету розробки діаграми даного різновиду.

Хід роботи

Теоретичні відомості

Окрім діаграм IDEF0 AFPM підтримує діаграми в нотації IDEF3, які призначені для опису логіки взаємодії інформаційних потоків. IDEF3 або так звана workflowdiagramming, використовує графічний опис інформаційних потоків, взаємин між процесами обробки інформації і об’єктів, що є частиною цих процесів. Діаграми Workflow можуть бути використані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації, наприклад послідовність обробки замовлення або подій, які необхідно обробити за кінцевий час. Кожен сценарій супроводжується описом процесу і може бути використаний для документування кожної функції.

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

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

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

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

Unit of Work (UOW) (одиниці роботи) або так звані роботи (activity), є центральними компонентами моделі. В IDEF3 роботи зображаються прямокутниками з прямими кутами і мають ім’я, виражене дієслівним іменником, що позначає процес дії, одиночним або у складі фрази, і номер (ідентифікатор); інший іменник у складі тієї ж фрази зазвичай відображає основний вихід (результат) роботи (наприклад, "Виготовлення виробу"). Часто іменник в імені роботи змінюється в процесі моделювання, оскільки модель може уточнюватися і редагуватися. Ідентифікатор роботи привласнюється при створенні і не змінюється. Навіть якщо робота буде видалена, її ідентифікатор не використовуватиметься для інших робіт.

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

Рис. 27.1. Визначення типу зв’язків

Старша (Precedence) стрілка - суцільна лінія, що зв’язує одиниці робіт (UOW). Малюється зліва направо (Рис.27.2) або зверху вниз. Вказує, що робота-джерело повинна закінчитися перш, ніж робота-мета почнеться.

Рис. 27.2. Зв’язок „послідовність” („старша стрілка”)

Відношення (Relational Link) - пунктирна лінія (Рис. 27.3) , що використовується для зображення зв’язків між одиницями робіт (UOW), а також між одиницями робіт і об’єктами посилань.

Рис. 27.3. Зв’язок типу "Нечітке відношення"

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

Рис. 27.4. Об’єктний зв’язок між роботами

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

Найчастіше нечіткі відношення використовуються для опису спеціальних випадків зв’язків передування, наприклад для опису альтернативних варіантів тимчасового передування. Звернемося ще раз до Рис. 27.2. На Рис. 27.5 вертикальні лінії вказують початок і закінчення роботи 1 і 2. Відповідно, до рисунка внесення виправлень до роботи починається ПІСЛЯ ухвалення всіх зауважень від рецензентів.

Рис. 27.5. Часова шкала виконання роботи (Рис. 27.2)

Альтернатива зв’язку „послідовність” з Рис. 27.2 - зв’язок нечіткого відношення, представлений на Рис. 27.6. В даному випадку внесення виправлень починається у міру отримання зауважень від рецензентів (Рис.27.7 – часова шкала для нечiткого вiдношення), тобто до безпосереднього закінчення дії з ухвалення зауважень.

Рис. 27.6. Альтернатива „послідовності” (Рис. 27.2)

Рис. 27.7. Часова шкала виконання роботи (Рис. 27.2), використовуючи зв’язок "Нечітке відношення"

Відзначимо ще раз необхідність чіткого документування тимчасових обмежень між діями, сполученими "нечітким відношенням". Як приклад розглянемо ще одну часову шкалу (Рис. 27.8) для Рис. 27.2.

Рис. 27.8. Альтернативна часова шкала виконання роботи (Рис. 27.2) з використанням зв’язку "Нечітке відношення"

У випадку, зображеному на Рис. 27.8, внесення виправлень буде почато після отримання перших зауважень, проте буде закінчено перед тим, як всі зауваження від рецензентів будуть отримані і оброблені.

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

Перехрестя (Junction)

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

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

Таблиця 10.1

Типи перехресть

"І"-перехрестя. З’єднання цього типу ініціюють виконання всіх своїх кінцевих дій. Всі дії, приєднані до перехрестя злиття "І"-з’єднання, повинні завершитися, перш ніж може почати виконуватися наступна дія. На Рис. 27.10 після отримання замовлення ініціюється перевірка коштів і наявності товару, за умови виконання усіх умов проводиться оплата.

Рис. 27.10. Перехрестя типу "І" (асинхронне)

"Ексклюзивне АБО". Незалежно від кількості дій, приєднаних до згортаючого або розгортаючого з’єднання "Ексклюзивне АБО", ініційоване буде тільки одне з них, і тому тільки одне з них буде завершено перед тим, як будь-яка дія, наступна за злиттям "Ексклюзивне АБО", зможе початися. Рис. 27.11.

Рис. 27.11. Перехрестя типу "Ексклюзивне АБО"

Перехрестя "АБО". З’єднання цього типу призначені для опису ситуацій, які не можуть бути описані двома попередніми типами з’єднань. Аналогічно зв’язку нечіткого відношення, з’єднання "АБО" в основному визначається і описується безпосередньо системним аналітиком. На Рис. 27.12 з’єднання J2 може активувати перевірку даних чеку і (або) перевірку суми готівки. Перевірка чеку ініціюється, якщо покупець бажає розплатитися чеком, перевірка суми готівки – при оплаті готівкою. І та, і інша робота ініціюється при частковій оплаті чеком і частково готівкою.

Рис. 27.12. Перехрестя типу "Асинхронне АБО"

Перехрестя можуть комбінуватися для створення складніших правил розгалуження (Рис. 27.13). Комбінації перехресть слід використовувати з обережністю, оскільки переобтяжені діаграми можуть виявитися складними для сприйняття.

Рис. 27.13. Комбінація перехресть

Правила створення перехресть

Виходячи із логіки, на одній діаграмі IDEF3 може бути створене декілька перехресть різних типів. Певні поєднання перехресть для злиття і для розгалуження можуть приводити до логічних невідповідностей та суперечностей. Щоб уникнути конфліктів необхідно дотримуватись наступних правил, більшість яких є очевидні:

1. Кожному перехрестю злиття повинно передувати перехрестя розгалуження.

2. Перехрестя для злиття "І" не може слідувати за перехрестям розгалуження типу "АБО" (синхронного або асинхронного). В даному випадку можливий варіант, коли умова J7 ніколи не буде виконана, відповідно такий сценарій не може реалізуватися (Рис.27.14).

Рис. 27.14. Зазделегіть невірна побудова перехресть. Перехрестя для злиття "І" не може слідувати за перехрестям "АБО"

3. Перехрестя для злиття "І" не може слідувати за перехрестям для розгалуження типу "Ексклюзивне АБО". Якщо в попередньому випадку Робота 4 могла бути виконана, якщо були виконані роботи 2 та 3, то в даному випадку Робота 4 ніколи не буде виконана (Рис. 27.15).

Рис. 27.15. Невірне розміщення перехресть. Перехрестя І не може слідувати за перехрестям ексклюзивне АБО

4. Перехрестя для злиття типу ексклюзивне "АБО" не може слідувати за перехрестям типу "І" (Рис.27.16). Після завершення роботи 1 запускаються обидві роботи - 2 і 3, а для запуску роботи 4 необхідно, щоб завершилася одна і лише одна робота або 2, або 3.

Рис. 27.16. Невірне розміщення перехресть. Перехрестя для злиття ексклюзивне "АБО" не може слідувати за перехрестям "І"

5. Перехрестя, що має одну стрілку на вході, повинне мати більш ніж одну стрілку на виході і навпаки.

Об’єкт „посилання” (Referent).

Об’єкт „посилання” або „вказівник” – це спеціальні символи, які посилаються на інші розділи опису процесу. Вони виносяться на діаграму для залучення уваги читача до яких-небудь важливих аспектів моделі. Вказівник IDEF3 виражає деяку ідею, концепцію або дані, які не можна пов’язати із стрілкою, перехрестям або роботою. Для внесення об’єкту „посилання” служить кнопка Referent Tool на панелі інструментів.

Об’єкт-посилання зображається у вигляді прямокутника, схожого на прямокутник роботи. Ім’я об’єкту- посилання задається в діалозі Referent (Рис.27.17). Як ім’я можна використовувати ім’я будь-якої стрілки з інших діаграм або ім’я сутності з моделі даних. Об’єкти- посилання повинні бути пов’язані з роботами або перехрестями пунктирними лініями.

Ім’я об’єкта-посилання зазвичай включає його тип (наприклад, ОБ’ЄКТ, UOB) і ідентифікатор. На Рис. 27.18 зображений вказівник типу ОБ’ЄКТ. Відповідно при внесенні об’єктів-посилань крім імені слід вказати тип. Типи об’єктів-посилань наведені в табл. 27.2.

Таблиця 27.2

Типи об’єктів-посилань

Декомпозиція

Методологія IDEF3 дозволяє декомпозувати роботу багатократно, тобто робота може мати дочірні робіти. Можливість множинної декомпозиції пред’являє додаткові вимоги до нумерації робіт. Зазвичай номер роботи складається з номера батьківської роботи, версії декомпозиції і порядкового номера на поточній діаграмі, розділених крапкою (Рис. 27.18).

Оскільки моделі IDEF3 можуть одночасно розроблятися декількома командами, IDEF3 підтримує просту схему резервування номерів робіт в моделі. Кожному аналітикові попередньо виділяється унікальний діапазон номерів робіт, що забезпечує їх незалежність один від одного. Номер роботи вказується у діалоговому вікні Activity Properties-Name параметр Reference Number.

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

На діаграмах IDEF3 ім’я стрілки може бути відсутнім, хоча AFPM показує відсутність імені як помилку.

Призначення сценаріїв IDEF3 аналогічне FEO діаграм. Тобто метою їх створення є ілюстрація певного сценарію розвитку події із багатьох можливих, для більшої наочності. Для створення необхідно вибрати Diagram/Add IDEF3 Scenario.

Завдання 1. Побудова діаграми IDEF3

Ця робота є логічним продовженням практичних робіт №7-9

Алгоритм виконання

1. Відкрийте розроблену у попередніх роботах модель.

2. Перейдіть на діаграму А2 і декомпозуйте роботу "Збір настільних комп’ютерів" (Рис. 27.19).

Рис. 27.19. Діаграма А2 із об’єктом декомпозиції

3. У діалоговому вікні Activity Box Count (Рис. 27.20) встановіть число робіт 4 і нотацію IDEF3.

Рис. 27.20. Вибір нотації IDEF3 в діалозі Activity Box Count

4. В результаті буде створена діаграма IDEF3, що містить роботи Unit of Work (UOW). Зверніть увагу на номер діаграми. Правою кнопкою миші клацніть на роботі з номером 1, виберіть в контекстному меню Name і внесіть ім’я роботи "Підготовка компонентів" (Рис. 27.21).

Рис. 10.21. Діалогове вікно Activity Properties (Властивості робіт)

5. Потім на вкладці Definition внесіть визначення роботи з номером 1 "Готуються всі компоненти комп’ютера згідно специфікації замовлення" (Рис. 27.22).

Рис. 27.22. Діалогове вікно Activity Properties вкладка Definition

6. На вкладці UOW діалогового вікна Activity Properties (Рис. 27.23) внесіть властивості роботи 1 відповідно до даних Таблиці 27.3.

Таблиця 27.3

Властивості UOW діалогового вікна Activity Properties

Рис. 10.23. Діалогове вікно Activity Properties вкладка UOW

7. Додайте до діаграми ще 3 роботи (кнопка  ) і присвойте імена роботам з номерами 2-7 відповідно до даних таблиці 27.4.

Таблиця 27.4

Назви робіт

Рис. 27.24. Діаграма IDEF3 після присвоєння роботам назв

8. За допомогою кнопки  панелі інструментів створіть об’єкт-посилання. Внесіть ім’я об’єкту зовнішнього посилання "Компоненти". З’єднайте стрілкою об’єкт посилання і роботу "Підготовка компонентів" (Рис. 27.25).

Рис. 27.25. Об’єкт „посилання” і робота "Підготовка компонентів" пов’язані стрілкою

9. Поміняйте стиль стрілки на Referent, що зв’язує об’єкт- посилання і роботу "Підготовка компонентів", скориставшись діалоговим вікном Arrow Properties.

10. Пов’яжіть стрілкою роботи "Підготовка компонентів" (вихід) і "Встановлення материнської плати і жорсткого диску" (вхід). Змініть стиль стрілки на Object Flow. Результат виконання показаний на Рис. 27.26.

Рис. 27.26. Результат створення UOW і об’єкту посилання

11. За допомогою кнопки на па панелі інструментів внесіть два перехрестя типу "Асинхронне АБО".

12. Пов’яжіть роботи з перехрестями, як показано на Рис. 27.27.

Рис. 27.27. Діаграма IDEF3 після створення перехресть

13. Правою кнопкою клацніть на перехресті для розгалуження J1 (fan-out), виберіть Name і внесіть ім’я "Компоненти, які потрібні в специфікації замовлення".

14. За допомогою кнопки  панелі інструментів додайте до діаграми ще один об’єкт-посилання і привласніть йому ім’я "Програмне забезпечення".

15. Створіть два перехрестя типу "Ексклюзивне АБО". Пов’яжіть роботи і відповідні посилання, як це показано на Рис. 27.28.

Рис. 27.28. Результат створення IDEF3 діаграми

Завдання 2. Створення сценарію

1. Виберіть пункт головного меню Diagram/Add IDEF3 Scenario. Створіть діаграму сценарію "Сценарій збору настільних комп’ютерів" на основі діаграми IDEF3 "Збір настільних комп’ютерів" (А22.1), задавши параметри сценарію Copy contents of source diagram.

2. Видаліть елементи, що не входять в сценарій (Рис. 27.29).

3. Проаналізуйте отриману діаграму.

Рис. 27.29. Результат створення Сценарію збору настільних комп’ютерів

Завдання 3. Захистіть виконану роботу

Питання до захисту практичної роботи