Дефинирайте външния обект на dfd диаграма. Диаграми на потока от данни

Обща концепция

Метод за моделиране на процеса - поток от данни (DFD)

DFD ви позволяват да представите изискванията за проектираната системапод формата на йерархия от функционални компоненти (процеси), свързани с потоци от данни.

Целта на това представяне е да демонстрира как всеки процес трансформира своите входове в изходи и да разкрие връзките между тези процеси.

Пример. Америка 20-те години. Консултантът в офиса отбеляза всеки служител с кръг, а всеки документ, преминал между тях, със стрелка. Използвайки такава диаграма, той предложи схема за реорганизация, при която двама чиновници, които обменят много документи, са седнали наблизо, а чиновниците с малко взаимодействие са седнали на голямо разстояние един от друг. Така се ражда първият прототип на DFD.

За конструиране на DFD се използват две различни нотации, съответстващи на методите на Джордан и Хайн-Серсън. Допълнителни примери ще използват по-популярната днес нотация на Hein-Serson.

Системният модел описва асинхронния процес на трансформация на информацията. Разграждане контекстни диаграми(диаграми на горните нива) продължава, създавайки многостепенна йерархия от диаграми, докато се достигне нивото на декомпозиция, при което процесите стават елементарни и е невъзможно да се детайлизират по-нататък.

Основните компоненти на диаграмите на потока от данни са:

1. Външни субекти.

2. Системи и подсистеми.

3. Процеси.

4. Устройства за съхранение на данни.

5. Потоци от данни.

Външен субект– материален обект или индивид, който е източник или приемник на информация (клиенти, доставчици, клиенти, склад и т.н.) На диаграмите на потока от данни външен обект се обозначава с квадрат, хвърлящ сянка.

Системи и подсистемиса елементи от най-високото ниво на разлагане и се показват на контекстни диаграми като едно цяло.

Системите и подсистемите се разлагат на процеси– компоненти на диаграма, предназначени да трансформират входните потоци от данни в изходни в съответствие с определен алгоритъм.

Физически процесът може да бъде реализиран по различни начини: може да бъде отдел на организацията, който обработва входящи документи и издава отчети, или програма, или хардуерно реализирано логическо устройство и т.н.

Използването на глаголи като „процес“, „надграждане“ или „редактиране“ в диаграмите показва липса на разбиране на процеса и изисква допълнителен анализ.

Хранилище за данни– абстрактно устройство за съхраняване на информация. Предполага се, че информацията може да бъде поставена в устройство за съхранение по всяко време и изтеглена след известно време, като методите за поставяне и извличане от там могат да бъдат различни.

Физически устройството за съхранение на данни може да бъде изпълнено под формата на кутия в шкаф за файлове, маса в RAM, файлове на магнитни носители и др.

В диаграмата на потока от данни устройството за данни се идентифицира с буквата „D“ и произволно число. Името на устройството е избрано така, че да бъде най-информативно за дизайнера. Като цяло, устройството за съхранение на данни е прототип на бъдеща база данни и описанието на данните, съхранявани в него, трябва да бъде специфицирано в съответствие с информационния модел (ERD).

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

В диаграма потокът от данни е представен от линия, завършваща със стрелка, която показва посоката на потока. Всеки поток от данни има име, което отразява неговото съдържание.

При конструирането на DFD диаграми е обичайно да се използват следните препоръки:

1. Поставете от 3 до 6÷7 процеса на всяка диаграма.

3. Опитайте се да не използвате съкращения.

4. Не претрупвайте диаграмите с маловажни подробности.

9.3. Диаграми същност-връзка

Нотацията ERD за конструиране на диаграми обект-връзка включва девет основни компонента.

Най-често информационните модели от този тип се използват за проектиране на структура на база данни.

В основата на тази методология за графично моделиране на информационни системи е специална технология за конструиране на DFD диаграми на потока от данни. Много анализатори участваха в разработването на методологията на DFD, сред които трябва да се отбележи Е. Юрдън. Той е автор на една от първите графични нотации DFD. В момента най-често срещаната е така наречената нотация на Gene-Sarson, чиито основни елементи ще бъдат разгледани в този раздел.

Системният модел в контекста на DFD е представен под формата на някакъв информационен модел, чиито основни компоненти са различни потоци от данни, които прехвърлят информация от една подсистема в друга. Всяка от подсистемите извършва определени трансформации на входния поток от данни и предава резултатите от обработката на информацията под формата на потоци от данни към други подсистеми.

Основните компоненти на диаграмите на потока от данни са:

Външни субекти

Устройства за данни или съхранение

процеси

Потоци от данни

Системи/подсистеми

Външен субект е материален обект или индивид, който може да действа като източник или приемник на информация. Дефиницията на някакъв обект или система като външен обект не е строго фиксирана. Въпреки че външният обект е извън границите на разглежданата система, в процеса на по-нататъшен анализ някои външни обекти могат да бъдат прехвърлени вътре в диаграмата на системния модел. От друга страна, отделните процеси могат да бъдат преместени извън диаграмата и представени като външни обекти. Примерите за външни субекти включват: клиенти на организация, клиенти, персонал, доставчици.

Външен обект се обозначава с правоъгълник със сянка (фиг. 2.15), вътре в който е посочено името му. В този случай се препоръчва да се използва съществително име в именителен падеж като име. Понякога външен обект също се нарича терминатор.

Ориз. 2.15.Илюстрация на външен обект в диаграма на потока от данни

Процесът е набор от операции за трансформиране на входни потоци от данни в изходни потоци в съответствие със специфичен алгоритъм или правило. Въпреки че един процес може да бъде физически реализиран по различни начини, най-разпространеният е софтуерната реализация на процеса. Процесът в диаграмата на потока от данни е представен от заоблен правоъгълник (Фигура 2.16), разделен на три секции или полета с хоризонтални линии. Полето за номер на процеса служи за идентифициране на последния. Средното поле съдържа името на процеса. Като име се препоръчва да се използва глагол в неопределена форма с необходимите добавки. Долното поле съдържа указание за метода на физическо изпълнение на процеса.

Ориз. 2.16.Представяне на процес в диаграма на потока от данни

Ориз. 2.17.Илюстрация на подсистема в диаграма на потока от данни

Информационният модел на системата е изграден като определена йерархична диаграма под формата на така наречената контекстна диаграма, на която оригиналният модел е последователно представен под формата на модел на подсистеми на съответните процеси за преобразуване на данни. В този случай подсистемата или системата на контекстната диаграма на DFD е изобразена по същия начин като процеса - правоъгълник със заоблени върхове (фиг. 2.17).

Устройството за данни или хранилището е абстрактно устройство или метод за съхраняване на информация, която се движи между процесите. Предполага се, че данните могат да бъдат поставени в устройството по всяко време и изтеглени след известно време, а физическите методи за съхранение и извличане на данни могат да бъдат произволни. Устройството за съхранение на данни може да бъде физически реализирано по различни начини, но най-често се приема, че е реализирано в електронен вид на магнитен носител. Съхранението на данни на диаграмата на потока от данни е изобразено като правоъгълник с две полета (фиг. 2.18). Първото поле се използва за указване на номера на устройството или идентификатора, който започва с буквата "D". Второто поле се използва за посочване на името. В този случай се препоръчва да се използва съществително като име на устройството, което характеризира метода за съхраняване на съответната информация.

Ориз. 2.18.Илюстрация на устройство в диаграма на потока от данни

И накрая, потокът от данни определя качествения характер на информацията, предавана чрез някаква връзка от източника към приемника. Действителният поток от данни може да се предава по мрежа между два компютъра или по друг начин, който позволява данните да бъдат извлечени и възстановени в необходимия формат. Потокът от данни в DFD диаграма е представен от линия със стрелка в единия край, като стрелката показва посоката на потока от данни. Всеки поток от данни има собствено име, отразяващо неговото съдържание.

По този начин информационният модел на системата в DFD нотация е конструиран под формата на диаграми на потока от данни, които са графично представени с помощта на подходяща нотационна система. Като пример, помислете за опростен модел на процеса на получаване на определена сума в брой по кредитна карта от клиент на банка. Външните субекти в този пример са банков клиент и евентуално банков служител, който наблюдава процеса на обслужване на клиенти. Съхранението на данни може да бъде база данни за състоянието на сметките на отделни банкови клиенти. Индивидуалните потоци от данни отразяват естеството на предаваната информация, необходима за обслужване на банковия клиент. Съответният модел за този пример може да бъде представен като диаграма на потока от данни (Фигура 2.19).

Понастоящем диаграмите на потока от данни се използват в някои CASE инструменти за изграждане на информационни модели на системи за обработка на данни. Основният недостатък на тази методология също е свързан с липсата на изрични средства за обектно-ориентирано представяне на модели на сложни системи, както и за представяне на сложни алгоритми за обработка

данни. Тъй като DFD диаграмите не показват характеристиките на времето за изпълнение на отделните процеси и трансфера на данни между процесите, моделите на системи, които прилагат синхронна обработка на данни, не могат да бъдат адекватно представени в DFD нотация. Всички тези характеристики на методологията за анализ на структурни системи ограничиха възможностите за широкото му приложение и послужиха като основа за включването на подходящи инструменти в единен език за моделиране.

Ориз. 2.19.Примерна DFD диаграма за процеса на получаване на пари в брой от кредитна карта

Нека разгледаме изграждането на DFD модел на информационна система за верига от магазини, продаващи чанти. Нека допълним диаграмата IDEF0, построена в лабораторна работа № 1, с DFD диаграма. Нека изградим DFD диаграма за функция A4 „Анализиране на работата“ Вижте фиг. 4.

Ориз. 4. Пример за DFD диаграма

Упражнение

Научете метода DFD.
Допълнете функционалния модел на информационната система, изграден в лабораторна работа № 1, с диаграма на потока от данни за онези функционални блокове IDEF0 на модела, за които е необходимо да се покаже движението на данните.
Отговори на въпросите за сигурност.
Създаване на отчет (заглавна страница, задача, DFD диаграма)

Контролни въпроси

Какви процеси в системата се описват с помощта на диаграми на потока от данни?
Кои са основните обекти на диаграмите на потока от данни?
Използва ли се принципът на разлагане при конструиране на DFD диаграми?
Мястото, където стрелката се доближава до блоковете, или мястото, където стрелката излиза от блока, може да бъде произволно или подчинено на определени правила?
Как един обект се изолира във външна единица?

Литература

Федотова, Д.Е. CASE технологии: Workshop / D.E. Федотова, Ю.Д. Семенов, К.Н. Сискин. - М.: Гореща линия - Телеком, 2005. - 160 с.: ил.
Калашян, А.Н. Структурни бизнес модели: DFD технологии / A.N. Калашян, Г.Н. Калянов. - М.: Финанси и статистика, 2003.
DFD диаграми на потока от данни. - http://www.proinfotech.ru/dmdlr2.htm.
Методи за моделиране на бизнес процеси. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Изграждане на декомпозиционна диаграма в DFD нотация

Цел на работата:

конструиране на диаграма на разлагане в DFD нотация на една от IDEF0 диаграмите, конструирани в предишни лабораторни упражнения

Диаграмите на потока от данни (DFD) се използват за описание на потока от документи и обработката на информация. Подобно на IDEF0, DFD представлява системата, която се моделира като мрежа от взаимосвързани дейности. Те могат да се използват като допълнение към модела IDEF0 за по-ясно показване на текущите операции на документооборота в корпоративните системи за обработка на информация. Основната цел на DFD е да покаже как всяка работа трансформира своите входове в изходи и да разкрие връзките между тези работни места.

Всяка DFD диаграма може да съдържа дейности, външни обекти, стрелки (потоци от данни) и хранилища на данни.

Върши работа.Творбите са изобразени като правоъгълници със заоблени ъгли (фиг. 1), значението им съвпада със значението на творбите IDEF0 и IDEF3. Точно както IDEF3 работи, те имат входове и изходи, но не поддържат контроли и механизми като IDEF0. Всички аспекти на работата са равностойни. Всяка работа може да има множество стрелки, влизащи и излизащи.

Фигура 1. Работа в DFD

Външни субекти.Външните обекти представляват входове към и/или изходи от система. Един външен обект може едновременно да предоставя входове (функционира като доставчик) и да приема изходи (функционира като приемник). Външен субект е материален обект, като клиенти, персонал, доставчици, клиенти, склад. Дефинирането на обект или система като външен обект показва, че той е извън границите на анализираната система. Външните обекти са изобразени като правоъгълник със сянка и обикновено са разположени по краищата на диаграмата (фиг. 2).

Фигура 2. Външен обект в DFD

Стрелки (потоци от данни).Стрелките описват движението на обекти от една част на системата към друга (оттук следва, че DFD диаграмата не може да има гранични стрелки). Тъй като всички страни на DFD произведение са равни, стрелките могат да започват и завършват от всяка страна на правоъгълника. Стрелките могат да бъдат двупосочни.

Съхранение на данни.За разлика от стрелките, които описват обекти в движение, хранилищата за данни изобразяват обекти в покой (Фигура 3). Складът за данни е абстрактно устройство за съхраняване на информация, което може да бъде поставено в устройство по всяко време и изтеглено след известно време, като методите за съхранение и извличане могат да бъдат всякакви. Като цяло тя е прототип на бъдещата база данни, като описанието на съхраняваните в нея данни трябва да съответства на информационния модел (Entity-RelationshipDiagram).

Фигура 3. Съхранение на данни в DFD

Декомпозиция на работа IDEF0 в DFD диаграма.При декомпозиране на работа IDEF0 в DFD трябва да се предприемат следните стъпки:

премахнете всички гранични стрелки на DFD диаграмата;
създаване на подходящи външни обекти и хранилища на данни;
създаване на вътрешни стрелки, започващи от външни обекти, вместо гранични стрелки;
стрелки на тунелирана диаграма IDEF0

Не винаги е удобно да се придържате стриктно към правилата на DFD нотация, така че BPWin ви позволява да създавате гранични стрелки в DFD диаграми.

Построяване на декомпозиционна диаграма.Да разложим работата Доставка и доставкадиаграма A0 "Дейности на предприятие в сглобяването и продажбата на компютри и лаптопи." В тази работа идентифицирахме следните детски творби:

доставка на необходими компоненти - занимава се с дейности, свързани с намиране на подходящи доставчици и поръчка на необходимите компоненти от тях
съхранение на компоненти и сглобени компютри
експедиране на готови продукти - всички действия, свързани с опаковането, документацията и самото експедиране на готовите продукти

Нека подчертаем работата Доставка и доставкадиаграма A0 „Дейности на предприятие за сглобяване и продажба на компютри и лаптопи“, щракнете върху бутона „GotoChildDiagram“ на лентата с инструменти и изберете нотацията DFD. Когато създава дъщерна диаграма, BPWin пренася граничните стрелки на родителската работа, те трябва да бъдат премахнати и заменени с външни обекти. Стрелките на механизма, стрелките за контрол „Правила и процедури“, „Информация за управление“ и стрелката за изход „Отчети“ на дъщерната диаграма няма да се използват, за да не се претрупва диаграмата с по-малко значими детайли. Ще заменим останалите стрелки с външни обекти - бутонът "ExternalReferenceTool" на лентата с инструменти, в прозореца, който се показва, изберете превключвателя "Стрелка" и изберете желаното име от списъка (фиг. 4):

Фигура 4. Добавяне на външен обект

Фигура 5. Работни места и външни обекти

Централната работа тук е „Съхранение на компоненти и сглобени компютри“. На входа му постъпват сглобени компютри и компоненти, получени от доставчици, както и списък с компоненти, необходими за сглобяване на компютри. Резултатът от тази работа ще бъде необходимите компоненти (ако са налични), списък с липсващи компоненти, прехвърлени на входа на работата „Доставка на необходимите компоненти“ и сглобени компютри, прехвърлени за изпращане. Резултатите от работата „Доставка на необходимите компоненти“ и „Изпращане на готови продукти“ ще бъдат съответно поръчки до доставчици и готови продукти.

Следващата стъпка е да се определи каква информация е необходима за всяка работа, т.е. трябва да се постави на диаграмата на хранилището на данни (фиг. 6).

Фигура 6. Крайна диаграма на разлагане

Работата "Доставка на необходимите компоненти" работи с информация за доставчици и информация за направени поръчки при тези доставчици. Стрелката, свързваща работата и хранилището на данни „Списък с доставчици“ е двупосочна, т.к work може както да получава информация за съществуващи доставчици, така и да въвежда данни за нови доставчици. Стрелката, свързваща работата с хранилището на данни "Списък с поръчки" е еднопосочна, т.к работата въвежда само информация за направените поръчки.

Работата "Съхранение на компоненти и сглобени компютри" работи с информация за получени и издадени компоненти и сглобени компютри, поради което стрелките, свързващи работата със складовете за данни "Списък на компонентите" и "Списък на сглобените компютри" са двупосочни. Също така тази работа, при получаване на компоненти, трябва да направи бележка, че поръчката към доставчиците е изпълнена. За да направите това, той е свързан към хранилището на данни „Списък с поръчки“ с еднопосочна стрелка. Моля, имайте предвид, че в DFD диаграмите едно и също хранилище на данни може да бъде дублирано.

И накрая, заданието „Изпращане на готови продукти“ трябва да съхранява информация за завършени доставки. За да направите това, въведете съответното хранилище на данни - „Данни за пратката“.

Последната стъпка е да тунелирате стрелките на родителската работа (фиг. 7):

Фигура 7. IDEF0 диаграма с тунелирани стрелки за заданието Доставка и доставка.

кратко описание на произведението, което се разлага
диаграма на разлагане

Пример за DFD диаграма на процеса „Изготвяне на технологична спецификация“ с помощта на Bpwin

ИТ стандарти

В коментарите към една от предишните ми статии за IDEF0, един от потребителите поиска да ми каже повече за това какво е DFD. Концепцията е донякъде объркваща, много от моите клиенти също задават въпроси относно потоците от данни и стандартите за диаграми. Ето защо реших да посветя тази статия на DFD.

DFD е общоприето съкращение за английски език. data flow diagrams - диаграми на потока от данни. Това е името на методологията за графичен структурен анализ, която описва източници на данни и дестинации, външни за системата, логически функции, потоци от данни и хранилища на данни, до които се осъществява достъп. Диаграмата на потока от данни (DFD) е един от основните инструменти за структурен анализ и проектиране на информационни системи, съществували преди широкото използване на UML. Уикипедия

Според мен определението от рускоезичната Уикипедия е донякъде претоварено с информация и в резултат на това ненужно трудно за разбиране. Също така, аз лично вярвам, че DFD и UML са различни инструменти и следователно е неправилно да се каже, че DFD е просто предшественик на UML.

За себе си измислих следната формулировка:

DFD е нотация, предназначена да моделира информационни системи от гледна точка на съхранение, обработка и предаване на данни.

Защо се нуждаем от DFD нотация?

Исторически синтаксисът на тази нотация е използван в две версии - Yourdon и Gane-Sarson. Разликите между тях са в таблицата по-долу:

Аз самият използвам само един от вариантите според Хайн и Сарсън. Но когато проучвах материала, преди да напиша тази статия, видях тази таблица за сравнение. Вярвам, че това е важно не толкова за избор на опция за синтаксис, ще зависи повече от избора на софтуер за създаване на нотации и вашите лични предпочитания, но като ясна илюстрация на факта, че DFD няма твърд синтаксис, т.к. , например в BPMN. Има различни опции, които можете да използвате тук, важното е те да са ясни за вас и вашите клиенти. DFD нотацията е удобен инструмент за създаване на ad hoc диаграми, които могат да бъдат направени бързо и с максимална свобода.

Този тип нотация се използва, когато е необходимо описание на системата като хранилище на данни. Тези. нотацията трябва ясно да отговаря на въпросите:

От какво се състои една информационна система?
Какво е необходимо за обработка на информация?

Самата нотация DFD се състои от следните елементи:

Процес, т.е. функция или последователност от действия, които трябва да бъдат предприети, за да бъдат обработени данните. Това може да бъде създаване на поръчка, регистрация на клиент и др. Прието е да се използват глаголи в имената на процеси, т.е. „Създайте клиент“ (а не „създайте клиент“) или „обработете поръчка“ (а не „публикувайте поръчка“). Няма строга система от изисквания, като например в IDEF0 или BPMN, където нотациите имат строго дефиниран синтаксис, тъй като те могат да бъдат изпълними. Но все пак трябва да се спазват определени правила, за да не се предизвиква объркване, когато други хора четат DFD.
Външни субекти.Това са всякакви обекти, които не са включени в самата система, но са източник на информация за нея или получатели на каквато и да е информация от системата след обработка на данните. Това може да е човек, външна система, всеки носител за съхранение или съхранение на данни.
Съхранение на данни. Вътрешно съхранение на данни за процесите в системата. Получените данни преди обработката и резултатът след обработката, както и междинните стойности, трябва да се съхраняват някъде. Това са бази данни, таблици или всяка друга възможност за организиране и съхранение на данни. Тук ще се съхраняват клиентски данни, клиентски заявки, фактури и всякакви други данни, които са влезли в системата или са резултат от процеси на обработка.
Поток от данни. Нотацията се показва под формата на стрелки, които показват каква информация е включена и каква информация излиза от определен блок на диаграмата.

DFD нотацията може да опише всяко действие, включително процеса на продажба или доставка на стоки, работа с заявки от клиенти или закупуване на материали, от гледна точка на описание на системата. Тази нотация помага да се разбере от какво трябва да се състои системата и какво е необходимо за автоматизиране на бизнес процес. Но DFD не е описание на самия бизнес процес. Тук например няма такъв важен параметър като времето. Освен това тази нотация не предоставя условия и „разклонения“. В DFD разглеждаме откъде идват данните, какви данни са необходими, как се обработват и къде трябва да бъдат изпратени резултатите. Тези. Тази нотация описва не толкова самия процес, колкото движението на потоците от данни. За работа с процеси препоръчвам да използвате BPMN или IDEF3 (ще говоря за това друг път).

Как да създадете DFD нотации

Нека да разгледаме нотацията за автоматизация на продажбите като пример. Да кажем, че имаме клиент, който прави заявка през сайта или по телефона. Има мениджър, който регистрира това приложение. Така в системата се появяват данни - клиента и неговата поръчка. Служителят на склада трябва да види това и да изпрати стоките с всички необходими документи и да предаде документите на клиента.

Последователността изглежда така:

Клиентът предоставя своите данни и приложение.
Мениджърът проверява и въвежда получените данни в системата.
Складов работник генерира документи, например фактура, и изпраща стоките.
Клиентът получава стоката и пакет документи за нея.

Трябва да видим тази последователност от действия от гледна точка на съхранение на данни и работа с тях в ИТ системата.

От гледна точка на DFD имаме:

Купувачът е външен субект, който е източник на данни и получател на резултата.
Процес на обработка на поръчка (потвърждение и публикуване на данни в системата от мениджъра).
Приемане на поръчката в склада (след получаване на заявката).
Регистрация на пратката (създаване на необходимите документи).

Какви правила трябва да знаете, за да създадете DFD диаграма:

Всеки процес трябва да има поне един вход и един изход. Смисълът на процесите тук е да обработват данни и следователно процесът трябва да получава данни (входяща стрелка) и да ги предава някъде след обработка (изходяща стрелка);
Процесът на обработка на данни трябва да има външна входяща стрелка (данни от външен обект). За да започне такъв процес, не е достатъчно да се използват данни от хранилището, трябва да пристигне нова информация за последваща обработка;
Стрелките не могат директно да свързват хранилища за данни; всички връзки минават през процеси. Няма смисъл просто да премествате данни от едно място на друго и ето как директната връзка на две хранилища се чете със стрелка. Данните се получават, за да се извършат някои действия, в нашия пример се извършва процесът на продажба. А това е възможно само чрез обработка (процес);
Всички процеси трябва да бъдат свързани или с други процеси, или с други хранилища на данни. Процесите не съществуват сами по себе си и следователно резултатът трябва да бъде предаден някъде;
Разграждане. DFD диаграмите предоставят възможност за създаване на големи процеси и тяхното разлагане на подпроцеси с подробно описание на действията. Например, можем да създадем процес на „създаване на приложение“, който след това да се разложи на последователност от действия, например получаване на приложение, отделно – проверка и получаване на клиентски данни; ако продукт в онлайн магазин е продава се по поръчка, тогава и при създаване на приложение ще трябва да получите данни от доставчика за наличността на необходимите артикули и др. И тогава на горната диаграма ще имаме блока „обработка на приложения“ и когато се разложи, ще получим диаграма с подробна последователност от действия на този етап. В същото време на нито един етап няма да имаме условия и филиали. Ще има процес и разграждането му до 3-4 нива в дълбочина.

Как ще изглежда диаграмата (без разлагане, най-високо ниво):

И разлагането на основния елемент на нашата диаграма:

Къде се използват DFD нотации?

DFD диаграмите се използват активно в разработката на софтуер. при което:

хранилищата за данни са електронни таблици и бази данни,
външни субекти – клиенти или други бази данни, включително такива от други програми (интеграция и обмен на данни),
процесите са функциите и модулите, изпълнявани в системата.

DFD нотациите също са удобни за анализ, когато системата се разглежда от гледна точка на документооборота. В същото време можете ясно да видите къде се съхраняват данните, как се обменя документация, къде са допуснати грешки в организирането на бизнес процесите в този процес и т.н. Но тук използването на DFD диаграми изисква специално внимание. Това обаче не е описание на бизнес процес като такъв, а по-скоро диаграма на движение на данни по време на изпълнението на бизнес процеси. Но като спомагателна опция, включително за визуално демонстриране на клиента съществуващи проблеми и методи за оптимизиране на работата, този тип нотация е доста подходяща.

Например, за да идентифицирате проблеми с документооборота, дублиране на документи или, обратно, липсваща документация или електронни данни в системата, е много удобно да създадете отделно описание на бизнес процеса и след това DFD нотация за него. Или обратното, първо се създава DFD нотация, за да се разберат основите на бизнеса и характеристиките на прилагането на документния поток. Помага да се идентифицира например липсата на важни документи в системата за автоматизация, които действително са създадени (на хартия), но не се показват в системата по никакъв начин. След това се изгражда оптимизиран бизнес процес, като се вземат предвид идентифицираните нюанси на документооборота.

DFD нотациите станаха лесни!

Вярвам, че DFD нотацията наистина е много по-проста, отколкото изглежда на пръв поглед. Основното нещо е ясно да разберете ограниченията на изграждането на този тип диаграма (липса на условия, време и т.н.) и да ги приложите там, където точно този подход ще бъде по-удобен. Може би ще откриете своите приложения за DFD, които не описах по-горе. Моят списък съдържа само тези опции, които използвам на практика.

Особено удобното при DFD нотациите е, че не е нужно да се придържате към строги правила и синтаксис, както например в BPMN. Тези нотации няма да бъдат изпълними; те са необходими за разбиране на характеристиките на документния поток, структурата и последващата работа с данни. Следователно, ако вашата диаграма е ясна както за вас, така и за клиента, някои отклонения от стандартите на DFD са напълно приемливи.

По принцип можете да рисувате DFD диаграми където и както предпочитате. Но ако искате да работите с декомпозиция, да изградите система на различни нива на детайлност, тогава ще трябва да забравите „инструментите за рисуване“ (Visio, Paint и други подобни). Ще ви трябват специализирани програми за моделиране.

Лично аз използвам ERwin и го препоръчвам на всички. Една от причините за избора ми са характеристиките на разграждане. В ERwin, както и в някои други подобни системи, е възможно да се разлагат DFD процеси във формат IDEF3, т.е. основната диаграма ще бъде във формат DFD, а на най-общо ниво ще видите основните потоци от данни и „възлите“ на тяхната обработка. А с декомпозицията можете да използвате процесен подход, който също може да бъде много удобен за разработване на големи системи или работа с различни бизнес отдели.

Въпроси и отговори

Каква е разликата между DFD и UML?

Има нотационен език, наречен UML, който също се позиционира като нотация, управлявана от данни. Но в същото време UML вече е език за програмиране, има строг синтаксис и изисквания, но има и много повече възможности за описание на различни функции. DFD е нотация, която се използва по-свободно и е по-подходяща за планиране, проучване на възможни решения, обсъждане с клиента и т.н.

Ако сте разработчик и знаете UML, възможно е дори някои предварителни решения да ви бъде по-удобно да създавате в тази нотация. А за бизнес консултант DFD винаги ще бъде по-удобен като инструмент, тъй като бизнес консултантът не се нуждае от подробно описание на функциите от гледна точка на автоматизацията; това е задача на техническите специалисти. Но DFD спестява много време и усилия.

Въпреки това, DFD не трябва да се разглежда като опростена версия на UML. Въпреки сходството в подхода, това са различни инструменти, предназначени за различни цели.

Колко елемента могат да се използват в DFD?

За разлика от системите със твърд синтаксис и регулации, в DFD няма ограничение за броя на елементите, които могат да бъдат на една диаграма. За сравнение: в IDEF0 има редица такива елементи, след което има само детайлизиране (разлагане) или различни означения.
От една страна, това е голям плюс, тъй като липсата на ограничения дава максимална свобода и комфорт при изготвяне на нотация. От друга страна, не е препоръчително да злоупотребявате с тази свобода. Не забравяйте, че колкото повече елементи имате в една диаграма, толкова по-трудна е тя за четене.

Могат ли DFD нотациите да се използват за работа с клиенти?

По принцип никой не може да забрани това. Освен това, в ограничени количества, като илюстрация към някои от вашите обяснения, такива обозначения са идеални при обсъждане на характеристиките на проекта с клиента. Но все пак клиентите обикновено имат малко разбиране за проблемите на автоматизацията, структурата за съхранение на данни, възможностите за обработка и т.н. Всичко това е от компетенциите на разработчиците. И DFD нотациите са изградени, като се вземат предвид спецификите на работа с данни, така че все пак препоръчвам да ги използвате главно при обсъждане на проект със специалисти, при създаване на техническо описание и задание за разработчиците, за да повишите разбирането на разработчиците за същността и характеристиките на проекта. Дори обясняването на характеристиките на DFD нотациите на неподготвен клиент може да бъде трудно.

При изграждането на функционален модел на система, алтернатива на методологията () е методологията диаграми на потока от данни (Диаграми на потока от данни, DFD). За разлика от този, предназначен за проектиране на системи като цяло, DFD е предназначен за проектиране на информационни системи. Фокусът на тази методология върху проектирането на автоматизирани системи я прави удобен и по-изгоден инструмент при изграждането на функционален TO-BE модел.

При конструирането на диаграми се разграничават елементите на графичното обозначение, представени в табл. 6.1.

Таблица 6.1. Елементи на DFD графична нотация

Име	Йорданова нотация	Нотация на Gein-Sarson
Поток от данни
Процес (система, подсистема)
Хранилище за данни
Външен субект

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

Всеки поток от данни има име, което отразява неговото съдържание. Посоката на стрелката показва посоката на потока от данни. Понякога информацията може да се движи в една посока, да бъде обработена и да се върне обратно към своя източник. Тази ситуация може да се моделира или от два различни потока, или от един – двупосочен.

Дефинирането на даден обект, субект или система като външен обект показва, че той е извън границите на проектираната информационна система. Поради това външните обекти обикновено се показват само в контекстната DFD диаграма. По време на процеса на анализ и проектиране някои външни обекти могат да бъдат прехвърлени в диаграми на декомпозиция, ако е необходимо, или, обратно, част от процесите (подсистеми) могат да бъдат представени като външен обект.

Изграждането на функционален DFD модел започва, както в IDEF0, с разработването на контекстна диаграма. Той показва основния процес (самата система като цяло) и нейните връзки с външната среда (външни обекти). Това взаимодействие се показва чрез потоци от данни. Възможно е едновременно показване на няколко основни процеса или подсистеми върху контекстна диаграма. Пример за контекстна диаграма за разглеждания проблем е показан на следващата фигура.

Ориз. 6.23. Контекстна диаграма на системата за определяне на допустимите скорости (DFD методология)

Тази диаграма показва, че базите данни ARM-P (Track Service Workstation) или SBD-P (Consolidated DB – Track Fragment), съдържащи почти цялата необходима информация за пътните участъци, могат да се използват като източник на първоначални данни за работата на системата.

В същото време системата оставя възможност за ръчно въвеждане и настройка. Въпреки факта, че базите данни ARM-P или SBD-P са външни единици по отношение на системата, за по-добро възприемане те се показват като устройство за съхранение на данни.

По-нататъшният процес на проектиране се състои от конструиране на декомпозиционни диаграми, които се конструират (показващи устройството) само за процеси или подсистеми (системи) .

Диаграмата на разлагане на първото ниво на проектираната система е показана на следващата фигура.

Ориз. 6.24. Диаграма на разлагане на първо ниво (DFD методология)

На тази фигура липсват имена на някои от потоците от данни, свързани с устройствата. Това ви позволява да премахнете дублирането на етикети и в резултат на това да намалите наситеността на диаграмата.

При конструирането на диаграма на разлагане блоковете на системата в някои случаи се показват като процеси (името започва с глагол), в други - като подсистеми (името започва с думата „подсистема“). Това се прави, за да се илюстрират конвенциите за именуване на блокове. В същото време декомпозицията на системата може да бъде представена или чрез използване само на процеси, или само на подсистеми.

Контекстната диаграма и диаграмата на разлагане са направени с помощта на BPwin 4.0.

Решението за завършване на детайлизирането на процеса и използването на миниспецификацията се взема от дизайнера въз основа на следните критерии:

Процесът има сравнително малък брой входни и изходни потоци данни (2–3 потока);

Възможност за описание на процесите под формата на прост алгоритъм;

Възможност за описание на логиката на процеса с помощта на малка мини-спецификация (не повече от 20-30 реда).

DFD моделът, в допълнение към описанието на функционалния аспект на системата, също съдържа информация за информационните и компонентните аспекти. Наборът от устройства за съхранение на данни е прототип на бъдещата база данни, т.е. определя състава и структурата на информацията. Изграждането на диаграми с помощта на подсистеми като блокове показва състава и връзките на компонентите на бъдещата система.

6.12. DFD разширения за системи в реално време

Системите в реално време се изграждат, като правило, върху взаимодействието на компютърни технологии и различни физически устройства за събиране на информация (сензори, камери, микрофони и др.). Първите са дискретни преобразуватели на информация, вторите са предимно аналогови, т.е. генериране на информация под формата на непрекъснат поток. Друга особеност на такива системи е значителното пристрастие към управлението на обекти. За да се моделира поведението на системите в реално време, P. Ward и S. Mellor предложиха използването на допълнителни елементи на DFD.