Побудова ієрархії діаграм потоків даних

 

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

Ознаками складності (у змісті контексту) можуть виступати:

- наявність великої кількості зовнішніх сутностей (десять і більше);

- розподілена природа системи;

- багатофункціональність системи із уже сформованим або виявленим угрупованням функцій в окремі підсистеми.

У зв'язку з цим для складних ПС може бути побудована ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний головний процес, а набір підсистем, з'єднаних потоками даних. Контекстні діаграми наступного рівня деталізують контекст і структуру окремих підсистем.

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

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

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

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

- правило нумерації - при деталізації процесів повинна підтримуватися їхня ієрархічна нумерація. Наприклад, процеси, що деталізують процес із номером 12, одержують номери 12.1, 12.2, 12.3 і т. д.

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

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

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

Приклад декомпозиції діаграми DFD задачі "Відвантаження продукції автотранспортом" наведено на рис. 4.15, 4.16.

Рис. 4.15 – Діаграма DFD першого рівня для рішення задачі