Основні об'єкти нотації eepc:

Функція. Служить для опису функцій (процедур, робіт), виконуваних підрозділами / співробітниками підприємства. Кожна функція повинна бути ініційована подією і повинна завершуватися подією; в кожну функцію не може входити більше однієї стрілки, "запускає" виконання функції, і виходити більше однієї стрілки, яка описує завершення виконання функції.

Подія. Служить для опису реальних подій, що впливають на виконання функцій.

Організаційна одиниця. Наприклад, управління або відділ.

Документ. Відображає реальні носії інформації, наприклад, паперові документи.

Прикладна система.

Кластер інформації. Характеризує набір сутностей і зв'язків між ними.

Зв'язок між об'єктами. Тип відносин між об'єктами, наприклад, активація виконання функції деяким подією.

Логічний оператор. Оператор "І", "АБО" або виключає "АБО", дозволяє описати розгалуження процесу.

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

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

3.2 Створення моделі валідації систем управління технологічними процесами на основі методології IDEF03

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

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

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

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

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

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

Аналогічно іншим технологіям моделювання дій, або в термінах IDEF3 «одиниця роботи» (Unit of Work - UOW), - інший важливий компонент моделі. Діаграми IDEF3 відображають дію у вигляді прямокутника. Як вже зазначалося, дії іменуються з використанням дієслів або віддієслівних іменників, кожному з дій присвоюється унікальний ідентифікаційний номер. Цей номер не використовується знову навіть у тому випадку, якщо в процесі побудови моделі дію видаляється. У діаграмах IDEF3 номер дії зазвичай передує номером його батька (рис. 3.1)

Рис. 3.1 Зображення та нумерація дії в діаграмі IDEF3

Зв'язки виділяють істотні взаємини між діями. Всі зв'язки в IDEF3 є односпрямованим, і хоча стрілка може починатися або закінчуватися на будь-якій стороні блоку, що позначає дію, діаграми IDEF3обично організовуються зліва направо таким чином, що стрілки починаються на правій і закінчуються на лівій стороні блоків. У табл. 3.1 наведено три можливих типи зв'язків.

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

Зображення	Назва	Призначення
	Тимчасове передування (Temporal pre­cedence)	Вихідна початкова дія має закінчитися раніше ніж остання дія почнеться
	Об’єктний потік (Object flow)	Вихід початкової дії є входом кінцевої дії. З цього слідую, що вихідна дія має закінчитися раніше чим кінцева дія почнеться.
	Нечітке відношення (Relationship)	Вид взаємодії між вихідною і кінцевою діями задається аналітиком окремо для кожного випадку використання такого відношення

Таблиця 3.1 Типи зв’язків

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

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

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

• розвертаючі сполуки використовуються для розбиття потоку. Завершення однієї дії викликає початок виконання кількох інших;

• згортаючі з'єднання об'єднують потоки. Завершення одного або декількох дій викликає початок виконання іншої дії.

У табл. 3.2 об'єднані три типи з'єднань.

Графічне позначення	Назва	Вид	Правила інформації
	З'єднання «і»	Розгортається	Кожна кінцева дія обов'язково ініціюється
		Згортається	Кожна вихідна дія обов'язково має завершитися
	З'єднання «ексклюзивне "або"»	Розгортається	Одна і тільки одна кінцева дія ініціюється
		Згортається	Одна і тільки одна вихідна дія повинна завершитися
	З'єднання «або»	Згортається	Одна або декілька кінцевих дій ініціюються
		Згортається	Одна або декілька вихідних дій повинні завершитися

Таблиця 3.2 Типи з’єднань

 «І»-з'єднання. Сполуки цього типу ініціюють виконання кінцевих дій. Всі дії, приєднані до згортання «і»-з'єднання, повинні завершитися, перш ніж почнеться виконання наступного дії.

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

З'єднання «або» призначено для опису ситуацій, які не можуть бути описані двома попередніми типами з'єднань. Аналогічно зв'язку нечіткого відношення з'єднання «або» в основному визначається і описується безпосередньо системним аналітиком.

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

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

Тип показчика	Призначення
ОБ’ЄКТ (OBJECT)	Для опису того, що в дії бере участь будь-яких заслуговуючий окремої уваги об'єкт
СИЛКА (GOTO)	Для реалізації циклічності виконання дій. Покажчик ПОСИЛАННЯ може відноситися і до з'єднання
ОДИНИЦЯ ДІЇ (Unit of Behavior — UOB)	Для багаторазового відображення на діаграмі одної і тієї ж дії.
ПРИМІТКА (NOTE)	Для документування будь-якої важливої ​​інформації загального характеру, що відноситься до зображеного на діаграмах. У цьому значенні ПОСИЛАННЯ служить альтернативою методу розміщення текстових нотаток безпосередньо на діаграмах
УТОЧНЕННЯ (Ela­boration — ELAB)	Для уточнення або більшдокладного опису зображеного на діаграмі. Покажчик УТОЧНЕННЯ зазвичай використовується для опису логіки розгалуження сполук

Таблиця 3.3 Показчики

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

Для коректної ідентифікації дій в моделі з багатьма декомпозиціями схема нумерації дій розширюється і поряд з номерами дії і його батька включає в себе номер декомпозиції. Наприклад, в номері дії 1.2.5: 1 – номер заходів батьківської дії, 2 - номер декомпозиції, 5 - номер дії.

Рис.3.2 Структурна схема динамічної моделі валідації систем управління технологічними процесами харчової промисловості з декомпозицією контекстної діаграми 1.1.