Йерархия на диаграмата
На първо място, цялата система е представена като най-прост компонент - един блок и дъги, които са интерфейси с функции, външни за тази система. Името на блока е общо за цялата система.
След това блокът, който представлява системата като цяло, е описан подробно в следната диаграма. Представен е като няколко блока, свързани с интерфейсни дъги. Всеки
блокът на подробната диаграма е подфункция, чиито граници се определят от интерфейсни дъги. Всеки от блоковете на подробната диаграма може също да бъде детайлизиран на следващата диаграма в йерархията. При всяка стъпка на разлагане по-общата диаграма се нарича родител на по-подробната диаграма.
Всички диаграми са свързани помежду си чрез йерархично номериране на блокове: първото ниво е AO, второто е Al, A2 и т.н., третото е All, A12, A13 и т.н., където първите цифри са номера на родителския блок, а последният е номерът на конкретен блок от подробната диаграма.
Във всички случаи всяка подфункция може да съдържа само онези елементи, които са включени в оригиналната функция, и никой от тях не може да бъде пропуснат. Това е родителският блок
и неговите интерфейси осигуряват контекст. Нищо не може да се добави към него и нищо не може да се премахне от него.
Дъгите, влизащи и излизащи от блок в диаграма от най-високо ниво, са точно същите като дъгите, влизащи и излизащи от диаграма от по-ниско ниво, тъй като блокът и диаграмата представляват една и съща част от системата.
Последователността на операциите, времето на тяхното изпълнение не са посочени на SADT-диаграми. Обратна връзка, повторения, текущи процеси и припокриване (във времето)
Потоци от данни
Потокът от данни определя информацията, предавана презнякаква връзка от източника до дестинацията. Действителният поток от данни може да бъде информация, предадена по кабел между две устройства, изпратени писма, магнитни ленти или дискети, прехвърлени от един компютър на друг и т.н.
Фиг. 5. Поток от данни
Изграждане на йерархия от диаграми на потока от данни
Първата стъпка в изграждането на DPD йерархия е изграждането на контекстни диаграми. Обикновено при проектирането на сравнително прости IS се изгражда единична контекстна диаграма със звездна топология, в центъра на която е така нареченият основен процес, свързан с приемници и източници на информация, чрез които потребителите и други външни системи взаимодействат със системата.
Ако за сложна система се ограничим до една контекстна диаграма, тогава тя ще съдържа твърде много източници и приемници на информация, които е трудно да се подредят на лист хартия с нормален размер, и освен това единственият основен процес не разкрива структурата на разпределената система. Признаците за сложност (по отношение на контекста) могат да бъдат:
наличието на голям брой външни обекти (десет или повече);
разпределен характер на системата;
мултифункционалност на система с вече установено или идентифицирано групиране на функции в отделни подсистеми.
За сложни IS се изгражда йерархия от контекстни диаграми. В същото време контекстната диаграма от най-високо ниво съдържа не един основен процес, а набор от подсистеми, свързани с потоци от данни. Контекстните диаграми от следващо ниво описват контекста и структурата на подсистемите.
Йерархията на контекстните диаграми определя взаимодействието на основните функционални подсистеми на проектираната ИС както помежду си, така ии с външни входни и изходни потоци от данни и външни обекти (източници и приемници на информация), с които ИС взаимодейства.
Разработването на контекстни диаграми решава проблема за стриктното дефиниране на функционалната структура на ИС в най-ранния етап от нейното проектиране, което е особено важно за сложни многофункционални системи, в чието разработване участват различни организации и развойни екипи.
След изграждането на контекстни диаграми, полученият модел трябва да бъде проверен за пълнотата на първоначалните данни за системните обекти и изолацията на обектите (липса на информационни връзки с други обекти).
За всяка подсистема, присъстваща на контекстните диаграми, нейното детайлизиране се извършва с помощта на DPD. Всеки процес на DPD от своя страна може да бъде детайлизиран с помощта на DPD или мини-спецификация. При детайлизиране трябва да се спазват следните правила:
правило за балансиране - означава, че при детайлизиране на подсистема или процес, детайлизиращата диаграма като външни източници/получатели на данни може да има само онези компоненти (подсистеми, процеси, външни обекти, хранилища на данни), с които детайлната подсистема или процес на родителската диаграма има информационни връзки;
правило за номериране - означава, че при детайлизиране на процесите трябва да се поддържа тяхното йерархично номериране. Например процеси, описващи процес номер 12, получават номера 12.1, 12.2, 12.3 и т.н.
Мини спецификацията (описание на логиката на процеса) трябва да формулира основните си функции по такъв начин, че в бъдеще специалистът, изпълняващ проекта, да може да ги изпълнява или да разработи подходяща програма.
Мини спецификацията е последният връх на йерархията на DPD. Решение за завършванедетайлизиране на процеса и използване на мини спецификация се приема от анализатора въз основа на следните критерии:
процесът има относително малък брой входни и изходни потоци, данни (2-3 потока);
възможността за описание на трансформацията на данни от процеса под формата на последователен алгоритъм;
изпълнение от процеса на единична логическа функция за преобразуване на входната информация в изходна;
възможността за описание на логиката на процеса с помощта на мини спецификация с малък обем (не повече от 20-30 реда).
При изграждането на DPD йерархия трябва да се пристъпи към детайлизиране на процесите само след определяне на съдържанието на всички потоци и хранилища на данни, което се описва с помощта на структури от данни. Структурите от данни са изградени от елементи, данни и могат да съдържат алтернативи, условия и повторения. Условното появяване означава, че този компонент може да не присъства в структурата. Алтернативно означава, че един от изброените елементи може да бъде включен в структурата. Итерация означава въвеждане на произволен брой елементи в определения диапазон. За всеки елемент от данни може да се посочи неговият тип (непрекъснати или дискретни данни). За непрекъснати данни може да се посочи мерната единица (kg, cm и т.н.), обхватът на стойностите, точността на представяне и формата на физическото кодиране. За дискретни данни може да се посочи таблица с валидни стойности.
След изграждането на пълен модел на системата, той трябва да бъде верифициран (проверен за пълнота и последователност). В един пълен модел всички негови обекти (подсистеми, процеси, потоци от данни) трябва да бъдат описани и детайлизирани в детайли. Идентифицираните неподробни обекти трябва да бъдат детайлизирани чрез връщане към предишните стъпки на разработка. В последователен модел за всички потоци от данни иустройства за съхранение на данни трябва да се спазва правилото за запазване на информацията: всички данни, пристигащи някъде, трябва да бъдат прочетени и всички прочетени данни трябва да бъдат записани.