- •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.2.Типи зв'язків
Зв'язки. Зв'язки виділяють істотні взаємини між діями. Всі зв'язки в IDEF3 є одно направленими, і, хоча стрілка може починатися або закінчуватися на будь-якій стороні блоку, що позначає дію, діаграми IDEF3 звичайно організовуються зліва направо таким чином, що стрілки починаються на правій і закінчуються на лівій стороні блоків. У табл. 3.1 приведені три можливих типу зв'язків.
Таблиця 3.1
Типи зв'язків в моделі IDEF3
Зображення |
Назва |
Призначення |
|
Часове передування (Temporal precedence) |
Початкова дія повинна завершитися перш, ніж кінцева дія зможе початися |
|
Об'єктний потік (Object flow) |
Вихід початкової дії є входом кінцевої дії. З цього, зокрема, витікає, що початкова дія повинна завершитися перш, ніж кінцева дія зможе початися |
|
Нечітке відношення (Relationship) |
Вид взаємодії між початковою і кінцевою діями задається аналітиком окремо для кожного випадку використання такого відношення |
Зв'язок типу «Часове передування». Як видно з назви зв'язки цього типа відображають, що початкова дія повинна повністю завершитися, перш ніж почнеться виконання кінцевї дії. Зв'язок повинен бути пойменований так, щоб людині, що проглядає модель, була зрозуміла причина її появи. У багатьох випадках завершення однієї дії ініціює початок виконання іншого, як показано на рис. 3.4. В даному прикладі автор повинен прийняти рекомендації рецензентів, перш ніж почати вносити необхідні зміни в роботу.
Рис. 3.4. Зв'язок типу "Передування" між діями 1.1 і 1.2
Зв'язок типу «Об'єктний потік». Однієї з причин, що устрічаються використання зв'язку типу "об'єктний потік" полягає у тому, що деякий об'єкт, що є результатом виконання початкової дії, необхідний для виконання кінцевої дії. Такий зв'язок відрізняється від зв'язку часового передування подвійним кінцем стрілки. Найменування потокових зв'язків повинні чітко ідентифікувати об'єкт, який передається з їх допомогою. Часова семантика об'єктних зв'язків аналогічна зв'язкам передування. Це означає, що початкова дія, що породжує об'єктний зв'язок, повинна завершитися, перш ніж кінцева дія почне виконуватися, як показано на рис. 3.5. У наведеному прикладі рахунок на оплату послуг є результатом виконання дії 1.1. Він необхідний для проведення оплати послуг.
Рис. 3.5. Об'єктний зв'язок між діями 1.1 і 1.2
Зв'язок типу «Нечітке відношення». Зв'язки цього типа використовуються для виділення відносин між діями, які неможливо описати з використанням попередніх або об'єктних зв'язків. Значення кожного такого зв'язку повинно бути визначено, оскільки зв'язки типу "Нечітке відношення" самі по собі не дозволяють ніяких обмежень. Одне із застосувань нечітких відносин — відображення взаємин між паралельними діями, що виконуються. Рис. 3.6 ілюструє фрагмент процесу запуску бензопили з водяним охолоджуванням і нечітке відношення між діями "Запустити двигун" та "Запустити водяний насос". Назва стрілки може бути використана для опису природи відношення, докладніше пояснення може бути приведено у вигляді окремого посилання.
Рис. 3.6. Зв'язок типу «Нечітке відношення»
Найчастіше нечіткі зв’язки використовуються для опису спеціальних випадків зв'язків передування, наприклад, для опису альтернативних варіантів часового передування. Звернемося ще раз до рис. 3.4. На рис. 3.7 вертикальні лінії показують початок і закінчення дій 1.1 і 1.2, що мають попередній зв'язок. Відповідно до рисунку, внесення виправлень в роботу починається ПІСЛЯ ухвалення всіх зауважень від рецензентів.
Рис.
3.7. Часова шкала виконання дії для 2.3
Альтернативна попереднього з рис. 3.4 нечіткого зв'язку представлено на рис. 3.8. В даному прикладі внесення виправлень починається у міру отримання зауважень від рецензентів, тобто до безпосереднього закінчення дії з ухвалення зауважень.
Рис. 3.8. Альтернатива зв'язку передування
На рис. 3.9 наведена відповідна цій ситуації часова шкала.
Рис. 3.9. Альтернативна часова шкала
Відзначимо ще раз необхідність чіткого документування часових обмежень між діями, сполученими нечітким відношенням. Як приклад, розглянемо ще одну часову шкалу (рис. 3.10) для рис. 3.4.
Рис. 3.10. Інший варіант альтернативної часової шкали
У випадку, зображеному на рис. 3.10, внесення виправлень буде розпочато після отримання перших зауважень, проте буде закінчено ПЕРЕД тим, як всі зауваження від рецензентів будуть одержані і оброблені.
Обидва розглянутих вище з варіантів часової альтернативної шкали можуть мати місце в реальності, тому коректна інтерпретація нечіткого відношення повинна бути документована в моделі. Важливо відзначити, що коректність в цьому випадку означає саме інтерпретацію, яка в точності відображає документовану ситуацію, а не інтерпретацію, ефективнішу для роботи системи, з погляду аналітика.
