Definujte externí entitu dfd diagramu. Diagramy toku dat

Obecná koncepce

Metoda procesního modelování - datový tok (DFD)

DFD umožňují prezentovat požadavky na navržený systém v podobě hierarchie funkčních komponent (procesů) propojených datovými toky.

Účelem této reprezentace je demonstrovat, jak každý proces přeměňuje své vstupy na výstupy, a odhalit vztahy mezi těmito procesy.

Příklad. Amerika 20. léta. Kancelářský konzultant označil každého úředníka kroužkem a každý dokument, který mezi nimi prošel, šipkou. Pomocí takového diagramu navrhl reorganizační schéma, ve kterém dva úředníci vyměňující si mnoho dokumentů seděli poblíž a úředníci s malou interakcí seděli ve velké vzdálenosti od sebe. Tak se zrodil první prototyp DFD.

Pro konstrukci DFD se používají dvě různé notace, odpovídající Jordanově a Hein-Sersonově metodě. Další příklady budou používat dnes populárnější Hein-Sersonův zápis.

Systémový model popisuje asynchronní proces transformace informace. Rozklad kontextové diagramy(diagramy vyšších úrovní) pokračuje a vytváří víceúrovňovou hierarchii diagramů, dokud není dosaženo úrovně dekompozice, na které se procesy stávají elementárními a není možné je dále rozvádět.

Hlavní součásti diagramů toku dat jsou:

1. Externí entity.

2. Systémy a subsystémy.

3. Procesy.

4. Zařízení pro ukládání dat.

5. Datové toky.

Externí entita– hmotný objekt nebo jednotlivec, který je zdrojem nebo příjemcem informací (zákazníci, dodavatelé, klienti, sklad atd.) Na diagramech toku dat je externí entita označena čtvercem vrhajícím stín.

Systémy a subsystémy jsou prvky nejvyšší úrovně dekompozice a jsou zobrazeny na kontextových diagramech jako jeden celek.

Systémy a subsystémy se rozkládají na procesy– komponenty diagramu určené k transformaci vstupních datových toků na výstupní v souladu se specifickým algoritmem.

Fyzicky může být proces implementován různými způsoby: může to být oddělení organizace, které zpracovává vstupní dokumenty a vydává zprávy, nebo program nebo hardwarově implementované logické zařízení atd.

Použití sloves jako „zpracovat“, „upgradovat“ nebo „upravit“ v diagramech naznačuje nedostatečné porozumění procesu a vyžaduje další analýzu.

Datové úložiště– abstraktní zařízení pro ukládání informací. Předpokládá se, že informace mohou být kdykoli umístěny do paměťového zařízení a po určité době načteny a způsoby umístění a získávání odtud mohou být různé.

Fyzicky lze datové úložiště implementovat ve formě krabice v kartotéce, tabulky v RAM, souborů na magnetických médiích atd.

V diagramu toku dat je datová jednotka označena písmenem „D“ a libovolným číslem. Název jednotky je zvolen tak, aby byl pro návrháře nejinformativnější. Obecně je datové úložiště prototypem budoucí databáze a popis dat v něm uložených musí být specifikován v souladu s informačním modelem (ERD).

Datový tok definuje informace přenášené prostřednictvím nějakého spojení ze zdroje do přijímače. Skutečným datovým tokem mohou být informace přenášené kabelem mezi dvěma zařízeními, dopisy zaslané poštou, magnetické pásky nebo diskety přenášené z jednoho počítače do druhého atd.

V diagramu je datový tok reprezentován čárou končící šipkou, která ukazuje směr toku. Každý datový proud má název, který odráží jeho obsah.

Při konstrukci diagramů DFD je běžné používat následující doporučení:

1.Na každý diagram umístěte 3 až 6÷7 procesů.

3. Snažte se nepoužívat zkratky.

4. Nezaplňujte schémata nedůležitými detaily.

9.3. Schémata vztahů entit

Zápis ERD pro vytváření diagramů vztahů mezi entitami zahrnuje devět hlavních komponent.

Nejčastěji se informační modely tohoto typu používají k návrhu struktury databáze.

Základem této metodiky pro grafické modelování informačních systémů je speciální technologie pro konstrukci DFD diagramů toku dat. Na vývoji metodiky DFD se podílelo mnoho analytiků, mezi nimiž je třeba zmínit E. Yourdona. Je autorem jedné z prvních grafických notací, DFD. V současnosti je nejrozšířenější tzv. Gene-Sarsonova notace, o jejíchž hlavních prvcích bude řeč v této části.

Systémový model v kontextu DFD je reprezentován ve formě nějakého informačního modelu, jehož hlavními součástmi jsou různé datové toky, které přenášejí informace z jednoho subsystému do druhého. Každý ze subsystémů provádí určité transformace vstupního datového toku a přenáší výsledky zpracování informací ve formě datových toků do dalších subsystémů.

Hlavní součásti diagramů toku dat jsou:

Externí entity

Datové disky nebo úložiště

Procesy

Datové toky

Systémy/subsystémy

Externí entita je hmotný objekt nebo jedinec, který může působit jako zdroj nebo příjemce informací. Definice nějakého objektu nebo systému jako externí entity není striktně pevná. Ačkoli je externí entita mimo hranice uvažovaného systému, v procesu další analýzy mohou být některé externí entity přeneseny do diagramu modelu systému. Na druhou stranu lze jednotlivé procesy přesunout mimo diagram a prezentovat je jako externí entity. Příklady externích subjektů zahrnují: klienty organizace, zákazníky, personál, dodavatele.

Vnější entita je označena obdélníkem se stínem (obr. 2.15), uvnitř kterého je naznačen její název. V tomto případě se doporučuje jako jméno použít podstatné jméno v nominativu. Někdy se externí entita také nazývá terminátor.

Rýže. 2.15. Ilustrace externí entity v diagramu toku dat

Proces je soubor operací pro transformaci vstupních datových proudů na výstupní proudy v souladu se specifickým algoritmem nebo pravidlem. Ačkoli proces může být fyzicky implementován různými způsoby, nejběžnější je softwarová implementace procesu. Proces v diagramu toku dat je reprezentován zaobleným obdélníkem (obrázek 2.16), rozděleným do tří sekcí nebo polí vodorovnými čarami. Pole číslo procesu slouží k identifikaci druhého. Prostřední pole obsahuje název procesu. Jako jméno se doporučuje používat sloveso v neurčitém tvaru s nezbytnými doplňky. Spodní pole obsahuje údaj o způsobu fyzické realizace procesu.

Rýže. 2.16. Reprezentace procesu v diagramu toku dat

Rýže. 2.17. Ilustrace subsystému v diagramu toku dat

Informační model systému je postaven jako určitý hierarchický diagram ve formě tzv. kontextového diagramu, na kterém je důsledně prezentován původní model v podobě modelu subsystémů odpovídajících procesů konverze dat. V tomto případě je subsystém nebo systém na kontextovém diagramu DFD znázorněn stejným způsobem jako proces - obdélník se zaoblenými vrcholy (obr. 2.17).

Datový disk nebo úložiště je abstraktní zařízení nebo metoda ukládání informací, které se pohybují mezi procesy. Předpokládá se, že data mohou být kdykoli umístěna na jednotku a po určité době načtena a fyzické metody pro ukládání a získávání dat mohou být libovolné. Zařízení pro ukládání dat může být fyzicky implementováno různými způsoby, ale nejčastěji se předpokládá implementace v elektronické podobě na magnetických médiích. Úložiště dat na diagramu toku dat je znázorněno jako obdélník se dvěma poli (obr. 2.18). První pole se používá k označení čísla jednotky nebo identifikátoru, který začíná písmenem „D“. Druhé pole se používá k označení názvu. V tomto případě se doporučuje použít jako název jednotky podstatné jméno, které charakterizuje způsob ukládání příslušných informací.

Rýže. 2.18. Ilustrace jednotky v diagramu toku dat

A konečně, datový tok určuje kvalitativní povahu informací přenášených prostřednictvím určitého spojení od zdroje k přijímači. Skutečný datový tok lze přenášet po síti mezi dvěma počítači nebo jakýmkoli jiným způsobem, který umožňuje získat a obnovit data v požadovaném formátu. Datový tok v DFD diagramu je reprezentován čárou se šipkou na jednom konci, přičemž šipka ukazuje směr toku dat. Každý datový tok má svůj vlastní název, který odráží jeho obsah.

Informační model systému v notaci DFD je tedy konstruován ve formě diagramů datových toků, které jsou graficky znázorněny pomocí příslušného notačního systému. Jako příklad uveďme zjednodušený model procesu přijetí určité částky hotovosti na kreditní kartu klientem banky. Externími entitami v tomto příkladu jsou bankovní zákazník a případně zaměstnanec banky, který dohlíží na proces zákaznických služeb. Datovým úložištěm může být databáze o stavu účtů jednotlivých klientů bank. Jednotlivé datové toky odrážejí povahu přenášených informací nezbytných pro obsluhu klienta banky. Odpovídající model pro tento příklad lze znázornit jako diagram toku dat (obrázek 2.19).

V současné době se diagramy datových toků používají v některých nástrojích CASE pro vytváření informačních modelů systémů zpracování dat. Hlavní nevýhoda této metodiky je také spojena s nedostatkem explicitních prostředků pro objektově orientovanou reprezentaci modelů komplexních systémů, stejně jako pro reprezentaci složitých algoritmů zpracování.

data. Vzhledem k tomu, že DFD diagramy neindikují charakteristiky doby provádění jednotlivých procesů a přenos dat mezi procesy, nelze modely systémů, které implementují synchronní zpracování dat, adekvátně reprezentovat v notaci DFD. Všechny tyto vlastnosti metodologie strukturálních systémů omezovaly možnosti jejího širokého uplatnění a sloužily jako základ pro zařazení vhodných nástrojů do jednotného modelovacího jazyka.

Rýže. 2.19. Příklad DFD diagramu pro proces příjmu nějaké hotovosti z kreditní karty

Zvažme vytvoření DFD modelu informačního systému pro řetězec obchodů prodávající tašky. Doplňme diagram IDEF0 zkonstruovaný v laboratorní práci č. 1 o DFD diagram. Vytvořme DFD diagram pro funkci A4 „Analyzovat práci“ Viz Obr. 4.

Rýže. 4. Příklad DFD diagramu

Cvičení

Naučte se metodu DFD.
Funkční model informačního systému, vybudovaný v laboratorní práci č. 1, doplňte o diagram datových toků pro ty funkční bloky IDEF0 modelu, u kterých je potřeba znázornit pohyb dat.
Odpověz na bezpečnostní otázky.
Vytvořte zprávu (titulní stránka, úkol, diagram DFD)

Kontrolní otázky

Jaké procesy v systému jsou popsány pomocí diagramů toku dat?
Jaké jsou hlavní objekty diagramů toku dat?
Používá se při konstrukci DFD diagramů princip rozkladu?
Místo, kde se šipka přibližuje k blokům nebo místo, kde šipka opouští blok, může být libovolné nebo podléhat určitým pravidlům?
Jak je objekt izolován do vnější entity?

Literatura

Fedotová, D.E. Technologie CASE: Workshop / D.E. Fedotová, Yu.D. Semenov, K.N. Pěnkava. - M.: Hotline - Telecom, 2005. - 160 s.: ill.
Kalashyan, A.N. Strukturální obchodní modely: Technologie DFD / A.N. Kalashyan, G.N. Kaljanov. - M.: Finance a statistika, 2003.
Diagramy toku dat DFD. - http://www.proinfotech.ru/dmdlr2.htm.
Metody modelování podnikových procesů. – http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Sestavení diagramu rozkladu v notaci DFD

Cíl práce:

vytvořit diagram rozkladu v notaci DFD jednoho z diagramů IDEF0 vytvořených v předchozích cvičeních

K popisu toku dokumentů a zpracování informací se používají diagramy toku dat (DFD). Stejně jako IDEF0 představuje DFD modelovaný systém jako síť vzájemně propojených činností. Lze je použít jako doplněk k modelu IDEF0 k přehlednějšímu zobrazení aktuálních operací toku dokumentů v podnikových systémech zpracování informací. Hlavním cílem DFD je ukázat, jak každá zakázka přeměňuje své vstupy na výstupy, a odhalit vztahy mezi těmito zakázkami.

Libovolný DFD diagram může obsahovat aktivity, externí entity, šipky (datové toky) a datová úložiště.

funguje. Díla jsou zobrazena jako obdélníky se zaoblenými rohy (obr. 1), jejich význam se shoduje s významem děl IDEF0 a IDEF3. Stejně jako funguje IDEF3, mají vstupy a výstupy, ale nepodporují ovládací prvky a mechanismy jako IDEF0. Všechny aspekty práce jsou rovnocenné. Každá úloha může mít více šipek směřujících dovnitř a ven.

Obrázek 1. Práce v DFD

Externí entity. Externí entity představují vstupy a/nebo výstupy systému. Jedna externí entita může současně poskytovat vstupy (fungující jako poskytovatel) a přijímat výstupy (fungující jako přijímač). Externí entita je hmotný objekt, jako jsou zákazníci, personál, dodavatelé, klienti, sklad. Definování objektu nebo systému jako externí entity znamená, že se nachází mimo hranice analyzovaného systému. Externí entity jsou znázorněny jako obdélník se stínem a jsou obvykle umístěny na okrajích diagramu (obr. 2).

Obrázek 2. Externí entita v DFD

Šipky (datové toky).Šipky popisují pohyb objektů z jedné části systému do druhé (z toho plyne, že DFD diagram nemůže mít hraniční šipky). Protože jsou všechny strany DFD práce stejné, mohou šipky začínat a končit na kterékoli straně obdélníku. Šipky mohou být obousměrné.

Úložiště dat. Na rozdíl od šipek, které popisují objekty v pohybu, datové sklady zobrazují objekty v klidu (obrázek 3). Datový sklad je abstraktní zařízení pro ukládání informací, které lze kdykoli umístit na jednotku a po určité době načíst, přičemž způsoby ukládání a získávání mohou být libovolné. Obecně se jedná o prototyp budoucí databáze a popis dat v ní uložených musí odpovídat informačnímu modelu (Entity-RelationshipDiagram).

Obrázek 3. Ukládání dat v DFD

Dekompozice práce IDEF0 do DFD diagramu. Při rozkladu práce IDEF0 na DFD je třeba provést následující kroky:

odstranit všechny hraniční šipky na diagramu DFD;
vytvořit vhodné externí entity a úložiště dat;
vytvořit vnitřní šipky vycházející z externích entit namísto hraničních šipek;
šipky na diagramu IDEF0 tunelované

Ne vždy je vhodné striktně dodržovat pravidla DFD notace, takže BPWin umožňuje vytvářet hraniční šipky v DFD diagramech.

Konstrukce diagramu rozkladu. Pojďme si dílo rozložit Zásilka a dodávka diagram A0 "Činnost podniku při montáži a prodeji počítačů a notebooků." V této práci jsme identifikovali následující dětské práce:

dodávka potřebných komponent - zabývá se činnostmi souvisejícími s vyhledáním vhodných dodavatelů a objednáním potřebných komponent u nich
Skladování součástí a sestavených počítačů
expedice hotových výrobků - veškeré úkony související s balením, dokumentací a samotnou expedicí hotových výrobků

Vyzdvihněme práci Zásilka a dodávka diagram A0 „Činnosti podniku pro montáž a prodej počítačů a notebooků“, klikněte na tlačítko „GotoChildDiagram“ na nástrojové liště a vyberte notaci DFD. Při vytváření podřízeného diagramu BPWin přenáší hraniční šipky nadřazeného díla, musí být odstraněny a nahrazeny externími entitami. Šipky mechanismu, ovládací šipky „Rules and Procedures“, „Management Information“ a „Reports“ (Zprávy) na podřízeném diagramu nebudou použity, aby nedošlo k zahlcení diagramu méně významnými detaily. Zbývající šipky nahradíme externími entitami - tlačítko "ExternalReferenceTool" na panelu nástrojů, v okně, které se objeví, vybereme přepínač "Arrow" a ze seznamu vybereme požadovaný název (obr. 4):

Obrázek 4. Přidání externí entity

Obrázek 5. Pracovní místa a externí entity

Ústředním úkolem je zde „Skladování součástek a sestavených počítačů“. Jeho vstupem jsou sestavené počítače a komponenty přijaté od dodavatelů a také seznam komponent nezbytných pro sestavení počítačů. Výstupem této práce budou potřebné součástky (pokud jsou k dispozici), seznam chybějících součástek převedený na vstup práce „Dodávka potřebných součástek“ a sestavené počítače předané k expedici. Výstupy prací „Dodávka potřebných komponent“ a „Expedice hotových výrobků“ budou objednávky dodavatelům a hotové výrobky.

Dalším krokem je určení, jaké informace jsou potřebné pro jednotlivé zakázky, tzn. musí být umístěn na diagramu datového skladu (obr. 6).

Obrázek 6. Schéma konečného rozkladu

Úloha "Dodávka potřebných komponent" pracuje s informacemi o dodavatelích a informacemi o objednávkách zadaných u těchto dodavatelů. Šipka spojující dílo a datový sklad „Seznam dodavatelů“ je obousměrná, protože práce může jak přijímat informace o stávajících dodavatelích, tak vkládat data o dodavatelích nových. Šipka spojující dílo s datovým skladem "Seznam zakázek" je jednosměrná, protože práce pouze zadává informace o provedených objednávkách.

Práce "Sklad součástek a sestavených počítačů" pracuje s informacemi o přijatých a vydaných součástkách a sestavených počítačích, proto jsou šipky spojující dílo s datovými sklady "Seznam součástek" a "Seznam sestavených počítačů" obousměrné. Také tato práce musí při příjmu komponent zaznamenat, že objednávka dodavatelům byla dokončena. K tomu je jednosměrnou šipkou připojen k datovému úložišti „Seznam objednávek“. Vezměte prosím na vědomí, že v diagramech DFD může být stejné úložiště dat duplikováno.

Nakonec musí úloha "Zásilka hotových výrobků" uchovávat informace o dokončených zásilkách. Chcete-li to provést, zadejte odpovídající úložiště dat - „Údaje o zásilce“.

Posledním krokem je vytunelování šipek nadřazeného díla (obr. 7):

Obrázek 7. Diagram IDEF0 s tunelovými šipkami pro úlohu Odeslání a Obstarání.

stručný popis rozloženého díla
diagram rozkladu

Příklad DFD diagramu procesu „Vypracování technologické specifikace“ pomocí Bpwin

IT standardy

V komentářích k jednomu z mých předchozích článků o IDEF0 mě jeden z uživatelů požádal, aby mi řekl více o tom, co je DFD. Koncept je poněkud matoucí, mnoho mých klientů se také ptá na datové toky a standardy grafů. Proto jsem se rozhodl věnovat tento článek DFD.

DFD je obecně přijímaná zkratka pro angličtinu. diagramy datových toků - diagramy datových toků. Toto je název metodologie grafické strukturální analýzy, která popisuje zdroje dat a cíle mimo systém, logické funkce, datové toky a datová úložiště, ke kterým se přistupuje. Diagram toku dat (DFD) je jedním z hlavních nástrojů pro strukturální analýzu a návrh informačních systémů, které existovaly před rozšířeným používáním UML. Wikipedie

Podle mého názoru je definice z ruskojazyčné Wikipedie poněkud přetížená informacemi a ve výsledku zbytečně složitá na pochopení. Osobně se také domnívám, že DFD a UML jsou různé nástroje, a proto je nesprávné říkat, že DFD je jednoduše předchůdcem UML.

Pro sebe jsem přišel s následující formulací:

DFD je zápis určený k modelování informačních systémů z hlediska ukládání, zpracování a přenosu dat.

Proč potřebujeme notaci DFD?

Historicky byla syntaxe této notace používána ve dvou verzích – Yourdon a Gane-Sarson. Rozdíly mezi nimi jsou v tabulce níže:

Já sám používám podle Heina a Sarsona pouze jednu z možností. Ale když jsem zkoumal materiál před psaním tohoto článku, viděl jsem tuto srovnávací tabulku. Domnívám se, že to není důležité ani tak pro volbu možnosti syntaxe, bude záležet spíše na volbě softwaru pro tvorbu notací a vašich osobních preferencích, ale jako jasná ilustrace toho, že DFD nemá rigidní syntaxi, jako , například v BPMN. Zde můžete využít různé možnosti, hlavní je, že jsou jasné vám i vašim klientům. Notace DFD je pohodlný nástroj pro vytváření ad-hoc diagramů, které lze provádět rychle a s maximální svobodou.

Tento typ zápisu se používá, když je vyžadován popis systému jako datového skladu. Tito. zápis by měl jasně odpovídat na otázky:

Z čeho se skládá informační systém?
Co je potřeba ke zpracování informací?

Samotný zápis DFD se skládá z následujících prvků:

Proces, tj. funkce nebo posloupnost akcí, které je nutné provést pro zpracování dat. Může to být vytvoření objednávky, registrace klienta atd. V názvech procesů je zvykem používat slovesa, tzn. „Vytvořit zákazníka“ (nikoli „vytvořit zákazníka“) nebo „zpracovat objednávku“ (nikoli „zadat objednávku“). Neexistuje žádný striktní systém požadavků, jako například v IDEF0 nebo BPMN, kde mají zápisy přesně definovanou syntaxi, protože mohou být spustitelné. Ale přesto by se měla dodržovat určitá pravidla, aby nedošlo ke zmatku, když ostatní lidé čtou DFD.
Externí entity. Jedná se o jakékoli objekty, které nejsou obsaženy v samotném systému, ale jsou pro něj zdrojem informací nebo příjemci jakýchkoliv informací ze systému po zpracování dat. Může to být osoba, externí systém, jakékoli paměťové médium nebo úložiště dat.
Úložiště dat. Interní úložiště dat pro procesy v systému. Přijatá data před zpracováním a výsledek po zpracování, stejně jako mezihodnoty, musí být někde uloženy. Jedná se o databáze, tabulky nebo jakoukoli jinou možnost organizace a ukládání dat. Zde budou uloženy zákaznické údaje, zákaznické požadavky, faktury a jakákoli další data, která vstoupila do systému nebo jsou výsledkem procesů zpracování.
Datový tok. Zápis je zobrazen ve formě šipek, které ukazují, jaké informace jsou obsaženy a jaké informace vycházejí z konkrétního bloku v diagramu.

Notace DFD může z pohledu popisu systému popsat jakoukoli akci, včetně procesu prodeje nebo expedice zboží, práce s požadavky zákazníků nebo nákupu materiálů. Tento zápis pomáhá pochopit, z čeho by se měl systém skládat a co je potřeba k automatizaci obchodního procesu. DFD však není popisem samotného obchodního procesu. Tady například není tak důležitý parametr jako čas. Tento zápis také neposkytuje podmínky a „forks“. V DFD se podíváme na to, odkud data pocházejí, jaká data jsou potřeba, jak se zpracovávají a kam se mají výsledky zasílat. Tito. Tento zápis nepopisuje ani tak samotný proces, jako spíše pohyb datových toků. Pro práci s procesy doporučuji použít BPMN nebo IDEF3 (o tom někdy jindy).

Jak vytvořit notace DFD

Podívejme se jako příklad na zápis automatizace prodeje. Řekněme, že máme klienta, který vytvoří žádost prostřednictvím webu nebo telefonu. Existuje manažer, který tuto aplikaci registruje. V systému se tak objevují data – klient a jeho objednávka. To musí vidět pracovník skladu a zboží odeslat se všemi potřebnými doklady a doklady předat klientovi.

Posloupnost vypadá takto:

Klient poskytuje svá data a aplikaci.
Manažer zkontroluje a vloží přijatá data do systému.
Skladník vygeneruje dokumenty, například fakturu, a odešle zboží.
Klient obdrží zboží a balíček dokumentů k němu.

Tuto posloupnost akcí musíme vidět z pohledu ukládání dat a práce s nimi v IT systému.

Z pohledu DFD máme:

Kupující je externí subjekt, který je zdrojem dat a příjemcem výsledku.
Proces zpracování objednávky (potvrzení a zaúčtování údajů do systému manažerem).
Vyzvednutí objednávky na skladě (po obdržení přihlášky).
Evidence zásilky (vytvoření potřebných dokumentů).

Jaká pravidla potřebujete znát pro vytvoření DFD diagramu:

Každý proces musí mít alespoň jeden vstup a jeden výstup. Smyslem procesů je zde zpracovávat data, a proto musí proces data přijímat (příchozí šipka) a po zpracování je někam dát (odchozí šipka);
Proces zpracování dat musí mít externí příchozí šipku (data od externí entity). Aby každý takový proces začal fungovat, nestačí použít data z úložiště, musí přijít nové informace pro následné zpracování;
Šipky nemohou přímo propojit úložiště dat, všechna připojení procházejí procesy. Nemá smysl data jednoduše přesouvat z jednoho místa na druhé a takto se šipkou čte přímé spojení dvou úložišť. Data jsou přijímána za účelem provedení některých akcí, v našem příkladu se provádí proces prodeje. A to je možné pouze prostřednictvím zpracování (procesu);
Všechny procesy musí být spojeny buď s jinými procesy, nebo s jinými datovými úložišti. Procesy neexistují samy o sobě, a proto je třeba výsledek někam přenést;
Rozklad. DFD diagramy poskytují možnost vytvářet velké procesy a rozkládat je na podprocesy s podrobným popisem akcí. Můžeme například vytvořit proces „vytvoření aplikace“, který lze následně rozložit na sekvenci akcí, například přijetí žádosti, samostatně – kontrola a získávání zákaznických dat; pokud je produkt v internetovém obchodě prodáváno na zakázku, pak také při vytváření aplikace budete potřebovat od dodavatele získat údaje o dostupnosti požadovaného zboží atp. A pak na horním diagramu budeme mít blok „zpracování aplikací“ a po rozložení získáme diagram s podrobným sledem akcí v této fázi. Přitom v žádné fázi nebudeme mít podmínky a pobočky. Dojde k procesu a jeho rozkladu až do hloubky 3-4 úrovní.

Jak bude diagram vypadat (bez rozkladu, nejvyšší úroveň):

A rozklad hlavního prvku našeho diagramu:

Kde se používají notace DFD?

DFD diagramy se aktivně používají při vývoji softwaru. kde:

datové sklady jsou tabulky a databáze,
externí subjekty – klienti nebo jiné databáze, včetně těch z jiných programů (integrace a výměna dat),
procesy jsou funkce a moduly prováděné v systému.

Notace DFD jsou také vhodné pro analýzu, když je systém uvažován z hlediska toku dokumentů. Zároveň můžete jasně vidět, kde jsou data uložena, jak probíhá výměna dokumentace, kde v tomto procesu došlo k chybám v organizaci obchodních procesů atd. Zde však použití DFD diagramů vyžaduje zvláštní opatrnost. Nejedná se však o popis obchodního procesu jako takového, ale spíše o schéma pohybu dat při implementaci obchodních procesů. Ale jako pomocná možnost, včetně vizuální demonstrace stávajících problémů a metod pro optimalizaci práce klientovi, je tento typ zápisu docela vhodný.

Například pro identifikaci problémů s tokem dokumentů, duplikací dokumentů nebo naopak chybějící dokumentace či elektronických dat v systému je velmi vhodné vytvořit samostatný popis obchodního procesu a následně k němu DFD notaci. Nebo naopak, nejprve se vytvoří zápis DFD, aby porozuměl základům podnikání a funkcím implementace toku dokumentů. Pomáhá identifikovat například absenci důležitých dokumentů v automatizačním systému, které jsou skutečně vytvořeny (na papíře), ale nejsou v systému nijak zobrazeny. A poté je vytvořen optimalizovaný obchodní proces, který zohledňuje zjištěné nuance toku dokumentů.

Snadné zápisy DFD!

Věřím, že zápis DFD je opravdu mnohem jednodušší, než se na první pohled zdá. Hlavní věcí je jasně porozumět omezením konstrukce tohoto typu diagramu (nedostatek podmínek, času atd.) a aplikovat je tam, kde přesně tento přístup bude pohodlnější. Možná najdete své vlastní použití pro DFD, které jsem nepopsal výše. Můj seznam obsahuje pouze ty možnosti, které využívám v praxi.

Na notacích DFD je obzvláště výhodné, že nemusíte dodržovat přísná pravidla a syntaxi, jako například v BPMN. Tyto zápisy nebudou spustitelné, jsou potřebné pro pochopení vlastností toku dokumentů, struktury a následné práce s daty. Pokud je tedy váš diagram jasný jak vám, tak zákazníkovi, jsou některé odchylky od standardů DFD zcela přijatelné.

V zásadě můžete kreslit DFD diagramy kdekoli a jak chcete. Pokud ale chcete pracovat s rozkladem, budovat systém na různých úrovních detailů, pak budete muset zapomenout na „kreslicí nástroje“ (Visio, Paint a podobně). Budete potřebovat specializované modelovací programy.

Osobně ERwin používám a všem doporučuji. Jedním z důvodů mého výběru jsou vlastnosti rozkladu. V ERwinu, stejně jako v některých jiných podobných systémech, je možné dekomponovat DFD procesy ve formátu IDEF3, tzn. hlavní diagram bude ve formátu DFD a na nejobecnější úrovni uvidíte hlavní datové toky a „uzly“ jejich zpracování. A s dekompozicí můžete použít procesní přístup, který může být také velmi vhodný pro vývoj velkých systémů nebo práci s různými obchodními odděleními.

Otázky a odpovědi

Jaký je rozdíl mezi DFD a UML?

Existuje notační jazyk zvaný UML, který se také staví jako notace řízená daty. Ale zároveň je UML už programovací jazyk, má přísnou syntaxi a požadavky, ale také mnohem více možností pro popis různých funkcí. DFD je zápis, který se používá volněji a je vhodnější pro plánování, studium možných variant řešení, diskusi se zákazníkem atp.

Pokud jste vývojář a znáte UML, je možné, že i některá předběžná řešení pro vás bude pohodlnější tvořit v tomto zápisu. A pro obchodního konzultanta bude DFD vždy výhodnější jako nástroj, protože obchodní konzultant nepotřebuje detailní popis funkcí z hlediska automatizace, to je úkolem technických specialistů. Ale DFD ušetří spoustu času a úsilí.

DFD by však nemělo být považováno za zjednodušenou verzi UML. Přes podobnost v přístupu se jedná o různé nástroje určené pro různé účely.

Kolik prvků lze použít v DFD?

Na rozdíl od systémů s rigidní syntaxí a předpisy není v DFD omezen počet prvků, které mohou být na jednom diagramu. Pro srovnání: v IDEF0 je takových prvků celá řada, pak už jen detailing (dekompozice) nebo různé zápisy.
Na jedné straně je to velké plus, protože absence omezení poskytuje maximální svobodu a pohodlí při vytváření notace. Na druhou stranu se nedoporučuje této svobody zneužívat. Pamatujte, že čím více prvků máte v diagramu, tím obtížnější je číst.

Lze zápisy DFD použít pro práci s klienty?

V zásadě to nikdo nemůže zakázat. Navíc, v omezeném množství, jako ilustraci některých vašich vysvětlení, jsou takové zápisy perfektní, když s klientem diskutujete o vlastnostech projektu. Přesto však klienti obvykle málo rozumí problémům automatizace, struktuře ukládání dat, možnostem zpracování atd. To vše je v kompetenci vývojářů. A DFD notace jsou stavěny s přihlédnutím ke specifikům práce s daty, takže je i tak doporučuji používat hlavně při probírání projektu se specialisty, při tvorbě technického popisu a zadání pro vývojáře, aby vývojáři lépe pochopili podstatu a vlastnosti projektu. Dokonce i vysvětlení vlastností DFD notací nepřipravenému zákazníkovi může být obtížné.

Při budování funkčního modelu systému je alternativou metodologie () metodologie diagramy toku dat (Data Flow Diagrams, DFD). Na rozdíl od návrhu určeného pro návrh systému obecně je DFD určeno pro návrh informačních systémů. Zaměření této metodiky na návrh automatizovaných systémů z ní činí pohodlný a výhodnější nástroj při budování funkčního modelu TO-BE.

Při konstrukci diagramů se rozlišují prvky grafického zápisu uvedené v tabulce. 6.1.

Tabulka 6.1. Prvky grafického zápisu DFD

název	Jordanova notace	Gein-Sarsonův zápis
Datový tok
Proces (systém, subsystém)
Datové úložiště
Externí entita

Datový tok definuje informaci (hmotný objekt) přenášenou prostřednictvím nějakého spojení ze zdroje do přijímače. Skutečným datovým tokem mohou být informace přenášené kabelem mezi dvěma zařízeními, dopisy zaslané poštou, magnetické pásky nebo diskety přenášené z jednoho počítače do druhého atd.

Každý datový proud má název, který odráží jeho obsah. Směr šipky ukazuje směr toku dat. Někdy se informace mohou pohybovat jedním směrem, být zpracovány a vrátit se zpět ke svému zdroji. Tuto situaci lze modelovat buď dvěma různými toky, nebo jedním – obousměrným.

Definice nějakého objektu, subjektu nebo systému jako externí entity naznačuje, že se nachází mimo hranice navrženého informačního systému. Z tohoto důvodu jsou externí entity obvykle zobrazeny pouze v kontextovém diagramu DFD. Během procesu analýzy a návrhu lze některé externí entity v případě potřeby přenést do dekompozičních diagramů, nebo naopak část procesů (subsystémů) reprezentovat jako externí entitu.

Konstrukce funkčního modelu DFD začíná, stejně jako v IDEF0, vývojem kontextového diagramu. Zobrazuje hlavní proces (samotný systém jako celek) a jeho vazby s vnějším prostředím (externí entity). Tato interakce je zobrazena prostřednictvím datových toků. Na kontextovém diagramu je možné zobrazit několik hlavních procesů nebo podsystémů najednou. Příklad kontextového diagramu pro uvažovaný problém je znázorněn na následujícím obrázku.

Rýže. 6.23. Kontextové schéma systému pro stanovení přípustných rychlostí (metodika DFD)

Tento diagram ukazuje, že databáze ARM-P (Track Service Workstation) nebo SBD-P (Consolidated DB – Track Fragment), obsahující téměř všechny potřebné informace o silničních úsecích, mohou být použity jako zdroj počátečních dat pro provoz systému.

Systém zároveň ponechává možnost ručního zadání a nastavení. Přestože jsou databáze ARM-P nebo SBD-P ve vztahu k systému externí entity, pro lepší vnímání jsou zobrazeny jako úložiště dat.

Další proces navrhování sestává z konstrukce dekompozičních diagramů, které jsou konstruovány (zobrazující zařízení) pouze pro procesy nebo subsystémy (systémy) .

Dekompoziční diagram první úrovně navrženého systému je na následujícím obrázku.

Rýže. 6.24. Diagram rozkladu první úrovně (metodika DFD)

Na tomto obrázku chybí některým datovým tokům spojeným s jednotkami názvy. To vám umožní eliminovat duplikaci štítků a v důsledku toho snížit saturaci diagramu.

Při konstrukci dekompozičního diagramu jsou bloky systému v některých případech zobrazeny jako procesy (název začíná slovesem), v jiných - jako podsystémy (název začíná slovem „subsystém“). Toto je provedeno pro ilustraci konvencí pojmenovávání bloků. Přitom rozklad systému mohl být reprezentován buď pouze pomocí procesů, nebo pouze subsystémů.

Kontextový diagram a diagram rozkladu jsou vytvořeny pomocí BPwin 4.0.

Rozhodnutí o dokončení podrobností procesu a použití mini-specifikace činí projektant na základě následujících kritérií:

Proces má relativně malý počet vstupních a výstupních datových toků (2–3 toky);

Možnost popisu procesů formou jednoduchého algoritmu;

Možnost popisu procesní logiky pomocí malé mini specifikace (ne více než 20–30 řádků).

Model DFD kromě popisu funkčního aspektu systému obsahuje také informace o aspektech informací a komponent. Sada zařízení pro ukládání dat je prototypem budoucí databáze, tzn. určuje složení a strukturu informací. Konstrukce diagramů pomocí subsystémů jako bloků ukazuje složení a spojení komponent budoucího systému.

6.12. Rozšíření DFD pro systémy reálného času

Systémy v reálném čase jsou zpravidla postaveny na interakci výpočetní techniky a různých fyzických zařízení pro sběr informací (senzory, kamery, mikrofony atd.). První jsou diskrétní převaděče informací, druhé jsou převážně analogové, tzn. generování informací ve formě nepřetržitého proudu. Dalším rysem takových systémů je značná zaujatost vůči správě objektů. Pro modelování chování systémů v reálném čase navrhli P. Ward a S. Mellor použití dalších prvků na DFD.