Ієрархія діаграм
Перш за все, вся система представляється у вигляді найпростішої компоненти - одного блоку і дуг, що є інтерфейсами із зовнішніми по відношенню до даної системи функціями. Ім'я блоку є загальним для всієї системи.
Потім блок, який представляє систему загалом, деталізується на наступній діаграмі. Він представляється як кількох блоків, з'єднаних інтерфейсними дугами. Кожен
блок детальної діаграми є підфункцією, межі якої визначені інтерфейсними дугами. Кожен з блоків детальної діаграми може бути деталізований на наступній в ієрархії діаграмі. На кожному кроці декомпозиції загальніша діаграма називається батьківською для більш детальної діаграми.
Усі діаграми пов'язують одна з одною ієрархічною нумерацією блоків: перший рівень — АТ, другий — Al, A2 тощо, третій — All, A12, А13 тощо, де перші цифри — номер батьківського блоку, а остання — номер конкретного блоку детальної діаграми
У всіх випадках кожна підфункція може містити лише ті елементи, які входять до вихідної функції, причому жодні з них не можуть бути опущені. Тобто батьківський блок
та його інтерфейси забезпечують контекст. До нього не можна нічого додати, і з нього не може бути видалено нічого.
Дуги, що входять у блок і що виходять з нього на діаграмі верхнього рівня, є точно тими самими, що і дуги, що входять в діаграму нижнього рівня і що виходять з неї, тому що блок і діаграма представляють одну і ту ж частину системи.
Послідовність операцій, час виконання не вказуються на SADT-диаграммах. Зворотні зв'язки, ітерації, процеси, що продовжуються, і перекриваються (за часом)
Потоки даних
Потік даних визначає інформацію, що передається черездеяке з'єднання джерела до приймача. Реальний потік даних може бути інформацією, що передається кабелем між двома пристроями, що пересилаються поштою листами, магнітними стрічками або дискетами, що переносяться з одного комп'ютера на інший і т.д.
Мал. 5. Потік даних
Побудова ієрархії діаграм потоків даних
Першим кроком при розбудові ієрархії ДПД є побудова контекстних діаграм. Зазвичай при проектуванні щодо простих ІС будується єдина контекстна діаграма із зіркоподібною топологією, в центрі якої знаходиться так званий головний процес, поєднаний із приймачами та джерелами інформації, за допомогою яких із системою взаємодіють користувачі та інші зовнішні системи.
Якщо ж для складної системи обмежитись єдиною контекстною діаграмою, то вона міститиме надто велику кількість джерел та приймачів інформації, які важко розташувати на аркуші паперу нормального формату, і крім того, єдиний головний процес не розкриває структури розподіленої системи. Ознаками складності (у сенсі контексту) можуть бути:
наявність великої кількості зовнішніх сутностей (десять і більше);
розподілена природа системи;
багатофункціональність системи з вже сформованим або виявленим угрупуванням функцій в окремі підсистеми.
Для складних ІС будується ієрархія контекстних діаграм. У цьому контекстна діаграма верхнього рівня містить єдиний головний процес, а набір підсистем, з'єднаних потоками даних. Контекстні діаграми наступного рівня деталізують контекст та структуру підсистем.
Ієрархія контекстних діаграм визначає взаємодію основних функціональних підсистем проектованої ІВ як між собою, такі з зовнішніми вхідними та вихідними потоками даних та зовнішніми об'єктами (джерелами та приймачами інформації), з якими взаємодіє ІС.
Розробка контекстних діаграм вирішує проблему суворого визначення функціональної структури ІВ на ранній стадії її проектування, що особливо важливо для складних багатофункціональних систем, у розробці яких беруть участь різні організації та колективи розробників.
Після побудови контекстних діаграм, отриману модель слід перевірити на повноту вихідних даних про об'єкти системи та ізольованість об'єктів (відсутність інформаційних зв'язків з іншими об'єктами).
Для кожної підсистеми, яка є на контекстних діаграмах, виконується її деталізація за допомогою ДПД. Кожен процес на ДПД, своєю чергою, може бути деталізований за допомогою ДПД або мініспецифікації. При деталізації слід виконувати такі правила:
правило балансування - означає, що при деталізації підсистеми або процесу деталізуюча діаграма як зовнішні джерела/приймачі даних може мати тільки ті компоненти (підсистеми, процеси, зовнішні сутності, накопичувачі даних), з якими має інформаційний зв'язок підсистема, що деталізується, або процес на батьківській діаграмі;
правило нумерації - означає, що з деталізації процесів має підтримуватися їх ієрархічна нумерація. Наприклад, процеси, що деталізують процес із номером 12, одержують номери 12.1, 12.2, 12.3 і т.д.
p align="justify"> Міні специфікація (опис логіки процесу) повинна формулювати його основні функції таким чином, щоб надалі фахівець, що виконує реалізацію проекту, зміг виконати їх або розробити відповідну програму.
Міні специфікація є кінцевою вершиною ієрархії ДПД. Рішення про завершеннядеталізації процесу та використання міні специфікації приймається аналітиком виходячи з наступних критеріїв:
наявності у процесу щодо невеликої кількості вхідних та вихідних потоків, даних (2-3 потоки);
можливості опису перетворення даних процесом у вигляді послідовного алгоритму;
виконання процесом єдиної логічної функції перетворення вхідної інформації у вихідну;
можливості опису логіки процесу за допомогою міні-спеціфікації невеликого обсягу (не більше 20-30 рядків).
При побудові ієрархії ДПД переходити до деталізації процесів слід лише після визначення вмісту всіх потоків та накопичувачів даних, що описується за допомогою структур даних. Структури даних конструюються з елементів, даних та можуть містити альтернативи, умовні входження та ітерації. Умовне входження означає, що цей компонент може бути відсутнім у структурі. Альтернатива означає, що структуру може входити одне із перелічених елементів. Ітерація означає входження будь-якого числа елементів у вказаному діапазоні. Для кожного елемента даних може вказуватись його тип (безперервні або дискретні дані). Для безперервних даних може вказуватися одиниця виміру (кг, см тощо), діапазон значень, точність уявлення та форма фізичного кодування. Для дискретних даних може вказуватись таблиця допустимих значень.
Після побудови закінченої моделі системи її необхідно верифікувати (перевірити на повноту та узгодженість). У повній моделі всі її об'єкти (підсистеми, процеси, потоки даних) мають бути докладно описані та деталізовані. Виявлені об'єкти, що не деталізовані, слід деталізувати, повернувшись на попередні кроки розробки. Узгоджена модель для всіх потоків даних інакопичувачів даних має виконуватися правило збереження інформації: усі дані, що надходять кудись, повинні бути зчитані, а всі дані, що зчитуються, повинні бути записані.