Vývojový diagram procesu vývoje softwaru: Symboly, typy a příklady

Vývojový diagram procesu vývoje softwaru převádí posloupnost kroků, rozhodnutí a výsledků do diagramu, který si kdokoli může přečíst během několika sekund. Tam, kde odstavec textu vyžaduje pečlivé přečtení, aby se pochopilo pořadí operací a podmínky, které mění cestu, vývojový diagram to zobrazuje prostorově: začněte zde, proveďte toto, zkontrolujte tamtu podmínku, větvení doleva nebo doprava, pokračujte až do konce. Toto prostorové znázornění je důvodem, proč vývojové diagramy zůstávají jedním z nejpoužívanějších nástrojů pro tvorbu diagramů v softwarovém inženýrství, a to více než sedmdesát let po svém prvním zavedení.

Tato příručka pokrývá vše potřebné ke čtení, vytváření a používání vývojových diagramů v kontextu vývoje softwaru: standardní symboly a jejich význam, různé typy vývojových diagramů a jejich použití, pracovní příklady ve formátu, který lze okamžitě kopírovat a vykreslovat, a jak se vývojové diagramy propojují se skutečným kódem, který reprezentují, včetně toho, jak lze toto propojení generovat automaticky, nikoli ručně.

Co je to vývojový diagram ve vývoji softwaru?

Vývojový diagram je diagram, který znázorňuje proces, algoritmus nebo pracovní postup pomocí standardizovaných symbolů spojených šipkami, které ukazují směr toku. Ve vývoji softwaru vývojové diagramy mapují logiku programu nebo procesu: posloupnost operací, body, kde program činí rozhodnutí, a různé cesty, kterými se provádění může ubírat v závislosti na těchto rozhodnutích.

Vývojové diagramy sahají až do 20. let 20. století v průmyslovém inženýrství, kde se používaly k dokumentaci výrobních procesů. Tato technika byla formalizována pro výpočetní techniku ​​ve 40. a 50. letech 20. století a v době, kdy se strukturované programování stalo standardní praxí v 70. letech 20. století, se vývojové diagramy staly klíčovou součástí dokumentace návrhu softwaru. Dnes se vývojové diagramy aktivně používají pro návrh algoritmů, dokumentaci k zavádění, mapování obchodních procesů a sdělování logiky netechnickým zainteresovaným stranám, a to i přesto, že některé z rolí, které vývojové diagramy původně plnily, převzaly specializovanější typy diagramů (UML, sekvenční diagramy, stavové diagramy).

Jaký je rozdíl mezi vývojovým diagramem a diagramem vývoje procesu?

Tyto termíny se často používají zaměnitelně a ve většině kontextů je to neškodné. Někdy se však rozlišuje: vývojový diagram obvykle představuje logiku jednoho algoritmu nebo programu, rozhodnutí, smyček a větví v kódu. Diagram toku procesu (nebo vývojový diagram procesu) častěji představuje obchodní proces, sled aktivit napříč lidmi, odděleními nebo systémy, často bez detailní rozhodovací logiky vývojového diagramu na úrovni kódu. V praxi jsou symboly a konvence sdíleny mezi oběma a termín, který používáte, je do značné míry určen vaším publikem a oborovými konvencemi, spíše než striktní technickou hranicí.

Symboly vývojových diagramů: Kompletní referenční příručka

Symboly vývojových diagramů jsou standardizované, aby je každý čtenář bez ohledu na jazyk nebo zázemí mohl správně interpretovat. Níže uvedená tabulka zahrnuje všechny symboly používané ve standardních vývojových diagramech softwaru:

Symbol	Shape	Jméno	Význam
⬭	Oválný / Zaoblený obdélník	Terminátor (začátek/konec)	Označuje začátek nebo konec procesu
▭	Obdélník	Proces	Představuje jeden krok, akci nebo operaci
◇	diamant	Rozhodnutí	Bod větvení se dvěma nebo více možnými výsledky (Ano/Ne, Pravda/Nepravda)
▱	Rovnoběžník	Vstup výstup	Představuje data vstupující do procesu nebo z něj vystupující.
⬡	Šestiúhelník	PŘÍPRAVA	Představuje krok nastavení, například inicializaci čítače smyčky.
▭ (s dvojitým okrajem)	Předdefinovaný proces	Volání samostatného, ​​již definovaného procesu nebo podprogramu
⬠	Dokument	Představuje vytištěný nebo vygenerovaný dokument
○	Malý kruh	konektor	Spojuje dva body ve vývojovém diagramu, často se používá k zamezení křížení čar.
▽	Trojúhelník (špičkou dolů)	Spojit	Spojuje více cest do jedné
△	Trojúhelník (špičkou nahoru)	Výpis	Rozdělí jednu cestu na více
→	Šipka	Toková linka	Označuje směr toku procesu
⬢	Mimostránkový konektor	Označuje, že tok pokračuje na další stránce

Dva symboly, které by měl každý čtenář okamžitě rozpoznat, jsou obdélník (krok procesu) a diamant (bod rozhodnutí s více východy). Tyto dva samy o sobě pokrývají většinu obsahu jakéhokoli vývojového diagramu. Oválný/zaoblený terminátor označující začátek a konec doplňuje minimální slovní zásobu potřebnou ke správnému čtení většiny vývojových diagramů.

Typy vývojových diagramů používaných ve vývoji softwaru

Různé typy vývojových diagramů slouží různým účelům. Výběr nesprávného typu pro danou situaci vede k diagramu, který je technicky správný, ale hůře čitelný, než je nutné.

Typ vývojového diagramu	Co to ukazuje	Nejlepší pro použití
Vývojový diagram procesu	Postupné kroky v jednom procesu	Dokumentace algoritmu, logiky funkce nebo obchodní procedury
Vývojový diagram systému	Jak se data pohybují mezi hardwarovými a softwarovými komponentami	Dokumentace architektury na vysoké úrovni, mapování starších systémů
Vývojový diagram plavecké dráhy (multifunkční)	Kroky seskupené podle odpovědné osoby, týmu nebo systému	Procesy zahrnující více rolí nebo oddělení
Diagram toku dat (DFD)	Jak se data přesouvají mezi procesy, úložišti a externími entitami	Dokumentování transformací dat spíše než řídicí logiky
Diagram pracovního postupu	Předávání úkolů a schvalovací řetězce v obchodním procesu	Řízení projektů, schvalovací pracovní postupy, směrování tiketů
Diagram aktivit UML	Souběžné a sekvenční aktivity s formální notací UML	Dokumentace návrhu objektově orientovaného softwaru

Diagram toku dat vs. vývojový diagram: Jaký je rozdíl?

Toto je jeden z nejčastějších nejasností a zaslouží si přímou odpověď. Vývojový diagram ukazuje, jak to kontrolní tok: pořadí, ve kterém se kroky provádějí, a podmínky, které určují, která cesta se zvolí. Diagram toku dat (DFD) ukazuje datový tok: odkud data pocházejí, které procesy je transformují, kde jsou uložena a kam nakonec směřují, aniž by nutně ukazovalo pořadí operací nebo rozhodovací logiku.

Vývojový diagram odpovídá na otázku „co se děje, v jakém pořadí, za jakých podmínek?“. Diagram toku dat odpovídá na otázku „odkud tato data pocházejí, co je mění a kde končí?“. Mnoho reálných systémů těží z obou: vývojového diagramu pro dokumentaci logiky zpracování a DFD pro dokumentaci toho, jak se informace touto logikou pohybují.

Příklady vývojových diagramů ve vývoji softwaru

Níže uvedená syntaxe Mermaid se vykresluje přímo v GitHubu, GitLabu, Notionu a většině moderních dokumentačních platforem, což z ní činí standardní způsob, jak udržovat vývojové diagramy verzované společně s kódem, spíše než aby byly uchovávány jako samostatné statické obrazy.

Základní vývojový diagram procesu

Tento vývojový diagram ukazuje kanonický vzorec, který rozpozná každý vývojář: terminátor pro zahájení, krok procesu, rozhodovací diamant se dvěma výsledky a konvergence zpět k jednomu koncovému bodu. Každý vývojový diagram, bez ohledu na svou složitost, je sestaven z opakovaných instancí téhož vzoru.

Vývojový diagram se smyčkou

Smyčky ve vývojových diagramech jsou znázorněny šipkou, která se vrací k dřívějšímu bodu rozhodnutí, místo aby pokračovala vpřed. Toto je ekvivalent vývojového diagramu for or while smyčku v kódu a je to jeden z nejčastěji testovaných vzorů v úvodních kurzech programování, „nakreslete vývojový diagram pro nalezení největšího ze tří čísel“ a podobná cvičení téměř vždy vyžadují smyčku nebo vnořenou rozhodovací strukturu.

Příklad vývojového diagramu plavecké dráhy

Plavecké dráhy (nazývané také mezifunkční vývojové diagramy) seskupují kroky procesu podle toho, kdo je provádí, takže předávání mezi týmy nebo systémy je okamžitě viditelné. Tento formát je standardem pro dokumentaci obchodních procesů, které zahrnují více oddělení nebo externích stran.

Jak vytvořit vývojový diagram procesu vývoje softwaru

Krok 1: Definujte počáteční a koncový bod. Každý vývojový diagram potřebuje přesně jeden jasný počáteční bod a jeden nebo více jasných koncových bodů. Pokud proces, který dokumentujete, nemá zřejmý začátek a konec, není rozsah ještě dostatečně dobře definován pro efektivní vytvoření vývojového diagramu.

Krok 2: Uveďte všechny kroky v pořadí. Před přiřazením symbolů si kroky napište srozumitelným jazykem. Tím se oddělí definice logiky od práce s diagramem a snáze se odhalí chyby. Oprava chybějícího kroku v textovém seznamu je mnohem rychlejší než v napůl nakresleném diagramu.

Krok 3: Identifikujte každý bod rozhodnutí. Projděte si seznam kroků a označte každé místo, kde další akce závisí na podmínce. Každý bod rozhodnutí se stane diamantem s alespoň dvěma výstupními cestami a každá cesta musí být označena (Ano/Ne, Pravda/Nepravda nebo konkrétní podmínka).

Krok 4: Přiřaďte správné symboly. Každý krok namapujte na jeho symbol: obdélníky pro akce, kosočtverce pro rozhodnutí, rovnoběžníky pro vstup/výstup a ovály pro začátek a konec. Konzistentní používání symbolů je to, co dělá vývojový diagram čitelným i pro někoho, kdo není s konkrétním procesem obeznámen.

Krok 5: Spojte se směrovými šipkami. Každý symbol by měl mít jasné propojení mezi vstupem a výstupem (s výjimkou začátku, který nemá vstup, a konce, který nemá výstup). Šipky by měly směřovat v obecném konzistentním směru, obvykle shora dolů nebo zleva doprava, aby se předešlo vizuální nejasnosti.

Krok 6: Ověření trasováním každé cesty. Projděte si vývojový diagram ručně a sledujte všechny možné cesty od začátku do konce. Ověřte, že každá rozhodovací větev někam vede, že žádná cesta nevede k slepé uličce bez dosažení koncového bodu a že smyčky mají definovanou ukončovací podmínku.

Nástroje pro vývoj vývojových diagramů softwaru

Pro ručně vytvořené vývojové diagramy je v pracovních postupech vývoje softwaru standardních několik nástrojů:

Mořská panna a PlantUML jsou nástroje pro práci s diagramy jako kódem: vývojový diagram je definován jako text a vykresluje se automaticky, což zachovává jeho verzi řízenou současně se zdrojovým kódem, který dokumentuje. Toto je doporučený přístup pro jakýkoli vývojový diagram, který dokumentuje logiku kódu, protože jej lze aktualizovat ve stejném commitu jako změnu kódu, kterou popisuje.

Lucidchart, Microsoft Visio, a draw.io jsou univerzální nástroje pro tvorbu diagramů s rozhraním drag-and-drop, vhodné pro dokumentaci obchodních procesů, prezentace a diagramy spravované mimo systém správy verzí.

Nástroje pro psaní na bílé tabuli (fyzické tabule, Miro, FigJam) jsou vhodné pro kolaborativní návrhářské sezení, kde je vývojový diagram spíše pracovním artefaktem během diskuse než trvalým dokumentem.

Kompromisem mezi těmito kategoriemi je synchronizace: ručně spravované diagramy v Lucidchartu nebo Visiu zastarávají s tím, jak se mění podkladový proces nebo kód, protože aktualizace diagramu vyžaduje samostatný, ruční krok, na který se snadno zapomene. Diagramy jako kód i automatizované generování tento problém řeší tím, že přesnost diagramu je vázána na automatizovaný proces, nikoli na lidskou paměť.

Automatické generování vývojových diagramů z existujícího kódu

Ruční kreslení vývojového diagramu pro nový návrh funguje dobře. Ruční kreslení vývojového diagramu pro dokumentaci existujícího, složitého a nedokumentovaného systému se neškáluje a pokud se během dokumentace změní základní kód, výsledkem bude diagram, který je v době jeho dokončení již zastaralý.

U stávajících kódových základen, zejména u velkých nebo starších systémů, automatizované generování vývojových diagramů analyzuje skutečný zdrojový kód a vytváří vývojový diagram přímo z jeho řídicího toku, a to každý... if, každá smyčka, každé volání funkce vykreslené jako odpovídající symbol vývojového diagramu, aniž by člověk musel nejprve ručně sledovat logiku.

Toto rozlišení je nejdůležitější u starších systémů. Program v COBOLu, který byl v průběhu dvaceti let upravován tuctem vývojářů, nashromáždil podmíněnou logiku, které nikdo plně nerozumí. Ručně kreslený vývojový diagram takového programu by vyžadoval, aby si někdo nejprve přečetl a správně interpretoval každý řádek, tedy přesně ten problém, který má vývojový diagram řešit. Automatické generování ze skutečného zdrojového kódu vytváří přesný vývojový diagram bez ohledu na to, jak dobře kdo v současné době programu rozumí, protože je odvozen z toho, co kód skutečně dělá, spíše než z toho, co si někdo myslí, že dělá.

Jak SMART TS XL Generuje vývojové diagramy z vaší kódové základny

SMART TS XL vytváří vývojové diagramy, grafy volání a diagramy závislostí přímo z analýzy zdrojového kódu, COBOLu, JCL, Javy, Pythonu, RPG a dalších jazyků, místo aby je vývojáři museli kreslit ručně. Jedná se o zásadně odlišný přístup od univerzálních nástrojů pro tvorbu diagramů, jako je Lucidchart nebo Visio, které poskytují kreslicí plátna, ale nemají žádnou představu o tom, co váš kód skutečně dělá.

Jedno vizualizace kódu Tato funkce analyzuje tok řízení programu a automaticky vytváří přesný vývojový diagram jeho rozhodovací logiky, větví a smyček. Pro starší program v COBOLu s desítkami let nahromaděné podmíněné logiky to znamená, že kompletní a přesný vývojový diagram lze vygenerovat během několika okamžiků, místo aby to vyžadovalo dny ručního čtení kódu a kreslení diagramů.

Protože je vývojový diagram generován přímo z aktuálního stavu zdrojového kódu, nemůže se odchýlit od synchronizace tak, jak se to děje u ručně spravovaného diagramu. Pokaždé, když se změní podkladový program, regenerace vývojového diagramu vytvoří aktualizovaný diagram, který odráží skutečnou aktuální logiku, čímž se řeší problém synchronizace, který ovlivňuje každý tým spoléhající se na ručně kreslenou dokumentaci procesu.

Pro týmy dokumentující složité systémy, mapování závislostí aplikací Tato schopnost rozšiřuje tuto možnost nad rámec vývojových diagramů jednotlivých programů a ukazuje, jak se více programů, toků úloh a zdrojů dat propojuje v celém portfoliu aplikací, a odpovídá tak nejen na otázku „co tento program dělá?“, ale i na otázku „k čemu se tento program připojuje a co se připojuje k němu?“. Jak je popsáno v kontextu techniky vizualizace kóduAutomaticky generované diagramy řeší problém zastaralosti, který činí ručně spravovanou dokumentaci nespolehlivou v jakémkoli aktivně vyvíjeném systému.

Vývojové diagramy jsou komunikačním nástrojem, nikoli jen dokumentačním artefaktem

Hodnota vývojového diagramu nespočívá v samotném diagramu, ale ve sdíleném porozumění, které diagram vytváří mezi všemi, kdo se na něj dívají. Vývojový diagram, který přesně reprezentuje proces, ale na který se nikdo během vývoje, kontroly kódu nebo zaškolování neodkazuje, vytvořil dokumentaci, aniž by přinesl hodnotu. Vývojový diagram, který tým skutečně používá k diskusi o okrajových případech, k zaškolení nového vývojáře do neznámého modulu nebo k identifikaci chybějící větve pro ošetření chyb, splnil svůj účel.

Tato praktická hodnota závisí na aktuálnosti vývojového diagramu. Diagram nakreslený jednou během počátečního návrhu a nikdy neaktualizovaný se stává aktivně zavádějícím, jakmile se od něj kód odchýlí, což je horší než neexistence diagramu, protože to vyvolává falešnou jistotu. Ať už se jedná o praktiky „diagramy jako kód“, které uchovávají vývojový diagram ve stejném repozitáři jako kód, nebo o automatické generování, které odvozuje vývojový diagram od skutečného aktuálního stavu kódu, disciplína udržování přesnosti diagramu je to, co odlišuje vývojové diagramy, které skutečně pomáhají týmu, od vývojových diagramů, které se stanou zastaralými artefakty, kterým nikdo nevěří.