Лабораторна робота № 4. Дослідження структури та умов використання методології IDEF3

Мета роботи:

Розглянути визначення бізнес-процесу та спосіб його опису за допомогою методології IDEF3. Навчитися розробляти задачі у вигляді бізнес-процесу, описаного за методологією IDEF3. Моделювання діаграм PFDD та OSTN.

Результати навчання:

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

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

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

1.     Теоретичний матеріал

Стандарт IDEF3 – це методологія опису процесів, що розглядає послідовність виконання і причинно-наслідкові зв'язки між ситуаціями і подіями для структурного представлення знань про систему.

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

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

– Діаграм опису послідовності етапів процесу (Process Flow Description Diagrams, PFDD);

– Діаграми переходу стану об'єкта (Object State Transition Network, OSTN).

За допомогою діаграм опису послідовності етапів процесу (PFDD) документується послідовність і опис стадій обробки в рамках досліджуваного бізнес-процесу. Опис проводиться з точки зору стороннього спостерігача. Ключовими елементами є поняття, процес, логіка процесу.

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

Розглянемо елементи діаграми опису послідовності етапів процесу (PFDD). Основними елементами IDEF3-моделі є (рисунок 4.1):

– одиниці робіт;

– зв'язки;

– перехрестя;

– об'єкти посилань.

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

Дія в IDEF3 називається одиницею роботи (Unit of Work, UOW) і позначається прямокутником. Дії іменуються дієсловами або віддієслівним іменниками. Кожній дії призначається унікальний номер. Номер ідентифікатора процесу призначається послідовно.

Рисунок 4.1 – Позначення основних елементів IDEF3-моделі

Приклад функції:

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

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

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

Зв'язки між функціональними блоками можуть бути:

– тимчасові,

– логічні,

– причинно-наслідкові,

– природні,

– звичайні.

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

Існує два основних типи зв'язків, які використовуються в IDEF3 схемах:

– зв'язки пріоритету (старшинства)

– відносні (переривчасті) зв'язки.

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

Приклад позначення простої черговості:

Приклад застосування:

Існують наступні підвиди зв'язку простої черговості:

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

Зв'язок виглядає, як лінія з двома стрілками, але розташована посередині спрямована в протилежний бік. Цей варіант обмеження вказує на те, що елемент B (другий по послідовності) може бути виконаний раніше елемента A (перший по порядку). Більш того, для того, щоб дії в елементі A були успішно завершені і можна було перейти до наступних етапів, елемент B повинен виконуватися в обов'язковому порядку.

Зв'язок виглядає, як лінія зі стрілкою на кінці та багатокутником («зірочкою») посередині. Означає, що елементи A і B взаємопов'язані, тобто виконання одного без іншого неможливо та безглуздо, причому, це правило працює в обидві сторони.

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

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

Стрілка відносини (Relational Link) – пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (UOW), а також між одиницями робіт і об'єктами посилань. Значення задається аналітиком окремо для кожного випадку.

Усі зв'язки, які використовуються в схемі, в обов'язковому порядку маркуються і нумеруються.

Для маркування використовуються абревіатури від назв типів зв'язків :

– СП або PL (від precedence links) – позначення для зв'язків передування;

– СО або DL (від dashed links) – зв'язку відносин.

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

Приклад позначення:

Приклад використання:

Для реалізації варіантів дій в залежності від виконання певних умов і були створені Вузли.

За кількістю вхідних і вихідних стрілок вузли в IDEF3 діляться на два види:

– вузли сходження, в яких сходяться гілки різних підпроцесів.

– вузли розбіжності, які ділять один процес на кілька «гілок».

Паралельний вузол має позначення – логічне І. Він вказує, що підпроцеси, які запускаються після вузла або, навпаки, були запущені перед вузлом, виконуються одночасно. Позначаються такі вузли символом & (логічне «І»). Все, що виходить з вузла з цим символом, запускається паралельно.

Наприклад, у нас є процес A, далі йде паралельний вузол, з якого виходять стрілки до процесів В, С і D. Інформація з процесу A відправляється в вузол, після чого запускаються всі вихідні процеси, тобто ті самі В, С і D.

За часом ці процеси можуть запускатися в довільному порядку. У деяких випадках процес В вже буде завершено, а процес D тільки почнеться. Ці нюанси зазвичай описуються додатково – текстом і за допомогою спеціальних діаграм.

Всі процеси після паралельного вузла обов'язково будуть запущені. І виконані вони будуть паралельно, тобто незалежно один від одного, кожен з них заснований тільки на результатах процесу А.

В позначенні альтернативного вузла присутня буква «О» або «X».

– OR. У цьому випадку після вузла можуть запускатися один або кілька підпроцесів, в залежності від умови, що виконується в вузлі. Тобто гілки, які задовольняють умові, виконуються, інші – ні.

– XOR. У такому типі вузлів умова більш жорстка, в результаті виконується тільки одна з гілок, яка повністю відповідає умові.

Асинхронні вузли. Якщо процеси можуть запускатися асинхронно, тобто в різний час, то вузол має одну рису всередині прямокутника. При цьому, наприклад, процес B може бути запущений о 8 годині ранку, а процес C – о 2 годині дня або пізніше, в залежності від якихось умов. Позначається:

Синхронні вузли. Якщо нам важливо, щоб процеси після вузла були запущені одночасно, необхідно використовувати синхронний вузол. Він позначається двома вертикальними лініями всередині прямокутника – зліва і справа.

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

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

Всі з'єднання на діаграмі повинні бути парними. Однак при цьому типи з'єднань не зобов'язані збігатися. На діаграмі з'єднання зазвичай позначаються літерою «J» та цифрою.

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

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

– Перехрестя для злиття «І» не може слідувати за перехрестям для розгалуження типу синхронного або асинхронного «АБО».

– Перехрестя для злиття «І» не може слідувати за перехрестям типу виняткового «АБО».

– Перехрестя для злиття типу виняткового «АБО» не може слідувати за перехрестям для розгалуження типу «І»

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

Якщо діаграми PFDD технологічний процес «З точки зору спостерігача», то інший клас діаграм IDEF3 Діаграми переходу стану об'єкта (OSTN) дозволяє розглядати той же самий процес «З точки зору об'єкта». Стани об'єкту та Зміни стану є ключовими поняттями OSTN діаграми.

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

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

Наприклад:

Існують декілька типів таких об'єктів:

– Call and Continue Referent (Викликай та продовжуй). Використовується для виклику раніше описаного UOB без дублювання. Вказує, що в процесі виконання основного UOB необхідно буде звернутися до описаного раніше до моменту завершення поточного UOB.

–                   Call and Wait Referent (Викликай та чекай). Використовується для передачі управління або визначення циклу в процесі обробки. Показує, що в процесі виконання поточного UOB потрібно звернутися до описаного раніше, після чого обов'язково дочекатися його завершення, і тільки потім можна буде завершити поточний UOB.

– Note (Примітка).

Приклад позначення «Викликай та продовжуй»

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

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

Схематика об'єктів з великою кількістю одночасних за часом референтів зображуються наступним чином:

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

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

Розглянемо приклад діаграми PFDD (рисунок 4.2) для завдання «Забарвлення деталі» та діаграму OSTN (рисунок 4.3) для цього ж завдання.

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

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

2.     Завдання до лабораторної роботи №4

Оберіть з попередніх лабораторних занять одну або декілька підпроцесів. Створити для обраних процесів діаграму опису послідовності етапів процесу (PFDD) та діаграму переходу стану об'єкта (OSTN) методології IDEF3.