Лекція 2.1 Функціональне моделювання. Методології функціонального моделювання

2. Побудова діаграм потоків даних (DFD)

2.1. Компоненти діаграм потоків даних.

2.2. Правила побудови моделі DFD.

2.3. Етапи побудови моделі DFD.

 

2.1. Компоненти діаграми потоків даних- DFD

Практично, на сьогоднішній день розрізняють дві графічні нотації для DFD (які і підтримуються Case-засобами): Гейна-Сарсона та Йордана-Де Марко, оскільки Де Марко в процесі удосконалення свого методу почав використовувати запропоновані Йорданом графічні зображення.

Основні символи цих нотацій зображені на рис 1. До них належать:

Назва	Нотація Йордона	Нотація Гейна-Сарсона
Flow – Потік даних
Process (bubble) - Процес
Store – Сховище	назва
Terminator – Зовнішній об’єкт	назва

Рисунок 1. Основні символи діаграм потоків даних

Потоки даних – під ними розуміють об’єкти (дані), що передаються з однієї частини системи в іншгу, позначаються стрілками. Стрілка вказує напрямок руху даних і може бути як одно-, так і двонаправленою.

Процеси – призначені для отримання вихідних потоків даних із вхідних, відповідно до дії, що задається ім’ям процесу (аналог робіт в IDEF0). Крім імені процес має також унікальний номер для посилань на нього усередині діаграми.

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

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

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

Також здійснюється декомпозиція – спочатку процесу на контекстній діаграмі, а потім, на слідуючому рівні, й інших процесів. Процес декомпозиції продовжується доти, поки процеси можуть бути ефективно описані за допомогою коротких (до однієї сторінки) специфікацій – діаграм декомпозиції. Процеси нумеруються. Так, наприклад, якщо ми деталізуємо процес номер 2 на діаграмі першого рівня, розкриваючи його за допомогою DFD, що містить три процеси, то їхні номери будуть мати такий вигляд: 2.1, 2.2 і 2.3. Прості системи мабть 2-3 рівні декомпозиції, в складних їх зазвичай не більше восьми.

На рис.10.18. зображено взаємозв’язок діаграм потоків даних в нотації Йордана.

На рис.10.19. подано приклад діаграми декомпозиції в нотації DFD Гейна-Сарсона.

 

2.2. Правила побудови моделі DFD

Основними вимогами при побудові моделей DFD є:

· Розміщувати на кожній діаграмі від 3 до 6-7 процесів. Верхня границя відповідає людським можливостям одночасного сприйняття і розуміння структури складної системи, нижня границя обрана з позицій здорового глузду: немає необхідності деталізувати процес діаграмою, що містить всього один або два процеси.

· Не захаращувати діаграми несуттєвими на даному рівні деталями.

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

· Вибирати ясні імена процесів і потоків, для поліпшення розуміння діаграм, при цьому намагатися не використовувати абревіатури.

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

· Користуватися найпростішими діаграмними техніками – не використовувати без необхідності складні об'єкти.

· Відокремлювати керуючі структури від процесів.

2.3 Етапи побудови моделі

Відповідно до цих рекомендацій процес побудови моделі розбивається на наступні етапи:

1. Розподіл множини вимог і організація їх в основні функціональні групи.

2. Ідентифікація зовнішніх об'єктів, з якими система повинна бути зв'язана.

3. Ідентифікація основних видів інформації, що циркулює між системою і зовнішніми об'єктами.

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

5. Формування DFD першого рівня на базі процесів попередньої контекстної діаграми, перевірка основних вимог по DFD першого рівня.

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

7. Додавання визначень нових потоків у словник даних при кожній їхній появі на діаграмах.

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

9. Після побудови двох-трьох рівнів проведення ревізії з метою перевірки коректності і поліпшення зрозумілості моделі.

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