Діаграма потоків даних

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

Рисунок «A sample data flow diagram»

Рисунок «Data Flow diagram: Level 1 Diagram»

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

Історично склалося так, що для опису діаграм DFD використаються дві нотації - Йодана (Yourdon) і Гейна-Сарсона (Gane-Sarson), що відрізняються синтаксисом.

На наведеній нижче ілюстрації використана нотація Гейна-Сарсона:

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

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

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

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

Ме та методики потоків даних

Метою методики потоків даних є побудова моделі розглянутої системи у вигляді діаграми потоків даних (Data Flow Dіagram - DFD), що забезпечує правильний опис виходів (відгуків системи у вигляді даних) при заданому впливі на вхід системи (подачі сигналів через зовнішні інтерфейси). Діаграми потоків даних є основним засобом моделювання функціональних вимог до проектованої системи.

При ст воренні діаграми потоків даних ви користаються чотири ос новних поняття:

- потоки даних,

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

- процеси (роботи) перетворення вхідних потоків даних у вихідні,

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

- зовнішні сутності,

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

- накопичувачі даних (сховища).

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

Пр оцес побудови DFD

Пр оцес побудови DFD починається зі створення так званої основної діаграми типу "зірка", на якій представлений моделюємий процес і всі зовнішні сутності, з якими він взаємодіє:

Рисунок «Діаграма типу «зірка»»

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

Критерії складності методики потоків даних

- наявність великої кількості зовнішніх сутностей,

- багато-функціональність системи,

- її розподілений характер.

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

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

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

1. процес має два-три вхідних і вихідних потоку;

2. процес може бути описаний у вигляді перетворення вхідних даних у вихідні;

3. процес може бути описаний у вигляді послідовного алгоритму.

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

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

Найпростіший спосіб їх виділення полягає в аналізі таблиць подій. Події перетворюються в потоки даних від ініціатора події до запитуваного процесу, а реакції - у зворотний потік подій.

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

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

Після побудови потоків даних діаграма повинна бути перевірена на повноту та несуперечність.

По внота діаграми за безпечується, якщо в системі немає «висячих» процесів, не використовуваних у процесі перетворення вхідних потоків у вихідні.

Не суперечність системи за безпечується виконанням наборів формальних правил про можливі типи процесів:

на діаграмі не може бути потоку, що зв'язує дві зовнішні сутності - ця взаємодія видаляється з розгляду;

жодна сутність не може безпосередньо одержувати або віддавати інформацію в сховище даних - сховище даних є пасивним елементом, керованим за допомогою інтерфейсного процесу;

два сховища даних не можуть безпосередньо обмінюватися інформацією - ці сховища повинні бути об'єднані.

Пе реваги та недоліки

До пе реваг методики DFD ві дносяться:

- можливість однозначно визначити зовнішні сутності, аналізуючи потоки інформації усередині та поза системою;

- можливість проектування зверху вниз, що полегшує побудову моделі "як повинно бути";

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

До недоліків ме тодики DFD ві днесемо:

- необхідність штучного введення керуючих процесів, оскільки керуючі впливи (потоки) і керуючі процеси із точки зору DFD нічим не відрізняються від звичайних;

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

Поиск по сайту: