29. Типи зв’язків між функціями в функціональних діаграмах idef3. Наведіть приклади.

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

31. Таблиця 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, внесення виправлень буде розпочато після отримання перших зауважень, проте буде закінчено ПЕРЕД тим, як всі зауваження від рецензентів будуть одержані і оброблені.

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

29. Дайте характеристику різних підходів до створення діаграм потоків даних.

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

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

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

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

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