- •1. Системний підхід при створення інформаційно-управляючих систем (іус)
- •1.1. Загальні відомості про автоматизовані системи управління та інформаційно-управляючі системи
- •Вхід вплив вихід
- •Автоматизовані системи управління та інформаційно-управляючі системи
- •1.2 Основні принципи створення асу (іус)
- •Основний виробничий
- •Допоміжний виробничий
- •Контроль і аналіз
- •1.3. Підходи до створення іус
- •2. Інструментальні засоби концептуального проектування
- •2.1. Загальні відомості про case
- •2.2. Методологія функціонального моделювання idef0
- •2.2.1 Моделі idef0
- •2.2.3 Межі і зв'язки
- •2.2.4 Тунелі
- •2.3 Побудова моделей idef0
- •2.3.1 Діаграми
- •2.3.2 Цикл "експерт-аналітик"
- •2.3.3 Побудова моделей
- •2.3.4 Точка зору
- •2.3.5 Розгалуження і сполучення моделей
- •2.3.6 Межі моделювання
- •2.3.7 Вибір найменування контекстного блоку
- •2.2.8 Визначення стрілок на контекстній діаграмі
- •2.3.9 Нумерація блоків і діаграм
- •2.3.10 Зв'язок між діаграмою і її батьківським функціональним блоком
- •2.3.11 Два підходи до початку моделювання ("завширшки" і "в глибину")
- •2.3.12 Завершення моделювання
- •2.3.13 Інші діаграми idef0
- •3. Методологія опису процесів бізнесу idef3
- •3.1. Призначення діаграм idef3
- •3.2. Два типи діаграм в idef3
- •3.3. Синтаксис і семантика моделей idef3
- •3.3.1 Моделі idef3
- •3.3.2.Типи зв'язків
- •3.3.3 З'єднання та розгалуження
- •3.3.4 Покажчики
- •3.3.5 Вимоги idef3 до опису процесів бізнесу
- •4. Структурний аналіз потоків даних (dfd — data flow diagrams)
- •4.1. Призначення діаграм потоків даних
- •4.2. Синтаксис і семантика діаграм потоків даних
- •4.2.1 Функціональні блоки
- •4.2.2 Зовнішні сутності
- •4.2.3 Стрілки (потоки даних)
- •4.2.4 Сховища даних
- •4.2.5 Галуження і об'єднання
- •4.3 Побудова діаграм потоків даних
- •4.3.1 Два підходи до побудови dfd-моделей
- •4.3.2 Нумерація об'єктів
- •Використані джерела інформации
3.3.4 Покажчики
Це спеціальні символи, які посилаються на інші розділи опису процесу.
Вони виносяться на діаграму для залучення уваги читача до яких-небудь важливих аспектів моделі.
Таблиця 3.4
Типи покажчиків моделі IDEF3
Тип покажчика |
Призначення |
ОБ'ЄКТ (OBJECT) |
Для опису того, що у дії бере участь який-небудь об'єкт, що заслуговує окремої уваги |
ПОСИЛАННЯ (GOTO) |
Для реалізації циклічності виконання дій. Покажчик ПОСИЛАННЯ може відноситися і до з'єднання |
ОДИНИЦЯ ДІЇ (Unit of Behavior —UOB) |
Для приміщення на діаграму додаткового екземпляра вже існуючої дії без зациклення. Наприклад, якщо дія "Підрахунок готівки" виконується кілька разів, вперше воно створюється як дія, а подальші його появи на діаграмі оформляються покажчиками UOB |
ЗАМІТКА (NOTE) |
Для документування будь-якої важливої інформації загального характеру, що відноситься до зображеного на діаграмах. У цьому сенсі ПОСИЛАННЯ служить альтернативим методом приміщення текстових заміток безпосередньо на діаграмах |
УТОЧНЕННЯ (Elaboration — ELAB) |
Для уточнення або докладнішого опису зображеного на діаграмі. Покажчики УТОЧНЕННЯ звичайно використовуються для опису логіки галуження в з'єднані |
Покажчик зображається на діаграмі у вигляді прямокутника, схожого на зображення дії. Ім'я покажчика звичайно включає його тип (наприклад, ОБ'ЄКТ, UOB і т.д.) і ідентифікатор. На рис. 3.18 зображений покажчик типу ОБ'ЄКТ (ліворуч) і приклад важливого, з точки зору зв’язку моделі, відображення між дією і об'єктом.
Рис. 3.18. Приклад об’єкту та посилання на нього
3.3.5 Вимоги idef3 до опису процесів бізнесу
Декомпозиція дій. Дії в IDEF3 можуть бути декомпозіровани, або розкладені на складові, для детальнішого аналізу. Декомпозірувати дію можна декілька разів. Це дозволяє документувати альтернативні потоки процесу в одній моделі. Для коректної ідентифікації дій, в моделі з множинними декомпозиціями, схема нумерації дій, розширюється і наряду з номерами дії і його батька, що включає порядковий номер декомпозиції. Наприклад, в номері дії 1.2.5: 1 — номер батьківської дії, 2 — номер декомпозиції, 5 — номер дії.
Визначення меж моделюванняь і точки зору. Перш ніж попросити експертів відповідної галузі підготувати опис модельованого процесу, повинні бути документовані межі моделювання, щоб експертам була зрозуміла необхідна глибина і повнота потрібного від них опису. Крім того, якщо точка зору аналітика на процес відрізняється від звичайної точки зору, для експерта, це повинно бути ясно і акуратно описано.
Цілком можливо, що експерти не зможуть зробити прийнятний опис без застосування формальних запитань автором моделі. У такому випадку автор повинен наперед приготувати набір питань таким чином, як журналіст наперед готує питання для інтерв'ю.
Визначення дій і об'єктів. Результатом роботи експертів звичайно є текстовий документ, що описує круг питань, які цікавлять аналітика. На додаток до нього може бути письмова документація, що дозволяє пролити світло на природу процесу, що вивчається. Незалежно від того, чи є інформація текстовою, або вербальною, вона аналізується і розділяється частинами мови для ідентифікації списку дій (дієслова і віддієслівні іменники), що становлять процес, і об'єктів (імена іменники), що беруть участь в процесі.
В деяких випадках можливо створення графічної моделі процесу у присутності експертів. Така модель також може бути розроблена після збору всієї необхідної інформації, що дозволяє не віднімати час експертів на деталі форматування тих, що виходять діаграм.
Оскільки моделі IDEF3 можуть одночасно розроблятися декількома командами IDEF3 підтримує просту схему резервування номерів дій в моделі. Кожному аналітику виділяється унікальний діапазон номерів дій, що забезпечує їх незалежність один від одного.
* * *
Отже IDEF3 — це спосіб опису процесів бізнесу, який потрібен для опису стану речей як впорядкованої послідовності подій з одночасним описом об'єктів, що мають безпосереднє відношення до процесу. IDEF3 добре пристосований для збору даних, потрібних для проведення структурного аналізу системи. Крім того IDEF3 застосовується при проведенні вартісного аналізу поведінки об’єкту моделювання.