Tarkvaraarendusprotsessi vooskeem: sümbolid, tüübid ja näited

Tarkvaraarendusprotsessi vooskeem teisendab sammude, otsuste ja tulemuste jada diagrammiks, mida igaüks saab sekunditega lugeda. Kui tekstilõik nõuab hoolikat lugemist, et mõista toimingute järjekorda ja teed muutvaid tingimusi, siis vooskeem näitab seda ruumiliselt: alusta siit, tee seda, kontrolli seda tingimust, hargne vasakule või paremale, jätka lõpuni. See ruumiline esitus on põhjus, miks vooskeem on enam kui seitsekümmend aastat pärast esmakordset kasutuselevõttu endiselt üks tarkvaratehnika enimkasutatavaid diagrammide koostamise tööriistu.

See juhend hõlmab kõike, mida on vaja vooskeemide lugemiseks, loomiseks ja rakendamiseks tarkvaraarenduse kontekstis: standardsümbolid ja igaühe tähendus, erinevat tüüpi vooskeemid ja millal neid kasutada, töönäited vormingus, mida saab kohe kopeerida ja renderdada, ning kuidas vooskeemid ühenduvad tegeliku koodiga, mida nad esindavad, sealhulgas kuidas seda seost saab genereerida automaatselt, mitte käsitsi joonistada.

Mis on tarkvaraarenduse vooskeem?

Vooskeem on diagramm, mis kujutab protsessi, algoritmi või töövoogu, kasutades standardiseeritud sümboleid, mis on ühendatud nooltega, mis näitavad voolu suunda. Tarkvaraarenduses kaardistavad vooskeem programmi või protsessi loogikat: toimingute järjestust, punkte, kus programm langetab otsuseid, ja erinevaid teid, mida täitmine võib nendest otsustest olenevalt võtta.

Vooskeemide ajalugu ulatub 1920. aastatesse tööstustehnikas, kus neid kasutati tootmisprotsesside dokumenteerimiseks. Arvutiteaduses formaliseeritud tehnika võeti kasutusele 1940. ja 1950. aastatel ning selleks ajaks, kui struktureeritud programmeerimine 1970. aastatel standardseks praktikaks sai, olid vooskeemidest saanud tarkvara projekteerimise dokumentatsiooni põhiosa. Tänapäeval kasutatakse vooskeeme aktiivselt algoritmide kujundamiseks, sissejuhatavaks dokumenteerimiseks, äriprotsesside kaardistamiseks ja loogika edastamiseks mitte-tehnilistele sidusrühmadele, isegi kui spetsialiseeritumad diagrammitüübid (UML, järjestusskeemid, olekuskeemid) on üle võtnud mõned rollid, mida vooskeemid algselt täitsid.

Mis vahe on vooskeemil ja protsessivooskeemil?

Neid termineid kasutatakse sageli sünonüümidena ja enamikus kontekstides on see kahjutu. Kuigi vahel tehakse vahet: vooskeem kujutab tavaliselt ühe algoritmi või programmi loogikat, otsuseid, tsükleid, harusid koodis. Protsessi vooskeem (või protsessi vooskeem) kujutab sagedamini äriprotsessi, tegevuste järjestust inimeste, osakondade või süsteemide vahel, sageli ilma kooditasandi vooskeemi peeneteralise otsustusloogikata. Praktikas on sümbolid ja konventsioonid mõlema vahel ühised ning kasutatava termini määravad suuresti teie sihtrühm ja valdkonna konventsioon, mitte ranged tehnilised piirid.

Vooskeemi sümbolid: täielik viide

Vooskeemi sümbolid on standardiseeritud, et iga lugeja, olenemata keelest või taustast, saaks vooskeemi õigesti tõlgendada. Allolev tabel hõlmab kõiki sümboleid, mida kasutatakse tarkvaraarenduse standardsetes vooskeemides:

Sümbol	kuju	Eesnimi	Tähendus
⬭	Ovaalne / ümar ristkülik	Terminaator (algus/lõpp)	Tähistab protsessi algust või lõppu
▭	ristkülik	Protsess	Esindab ühte sammu, toimingut või operatsiooni
◇	teemant	otsus	Hargnemispunkt kahe või enama võimaliku tulemusega (Jah/Ei, Tõene/Vale)
▱	Parallelogram	Input / Output	Esindab protsessi sisenevaid või protsessist lahkuvaid andmeid
⬡	Kuusnurk	Ettevalmistamine	Esindab seadistusetappi, näiteks tsükli loenduri initsialiseerimist
▭ (topeltäärisega)	Eelmääratletud protsess	Kutse eraldi, juba määratletud protsessile või alamprogrammile
⬠	Dokument	Esindab trükitud või loodud dokumenti
○	Väike ring	Connector	Ühendab vooskeemil kaks punkti, mida sageli kasutatakse joonte ületamise vältimiseks
▽	Kolmnurk (ots allapoole)	Merge	Kombineerib mitu rada üheks
△	Kolmnurk (ots ülespoole)	ekstrakt	Jagab ühe tee mitmeks
→	nool	Voolujoon	Näitab protsessi voolu suunda
⬢	Leheväline ühenduspesa	Näitab, et voog jätkub teisel lehel

Kaks sümbolit, mida iga lugeja peaks kohe ära tundma, on ristkülik (protsessietapp) ja romb (otsustuspunkt mitme väljapääsuga). Need kaks üksi katavad suurema osa iga vooskeemi sisust. Ovaalne/ümar terminaator, mis tähistab algust ja lõppu, täiendab minimaalset sõnavara, mida on vaja enamiku vooskeemide korrektseks lugemiseks.

Tarkvaraarenduses kasutatavate vooskeemide tüübid

Erinevat tüüpi vooskeemidel on erinevad eesmärgid. Olukorra jaoks vale tüübi valimine annab tulemuseks diagrammi, mis on tehniliselt korrektne, kuid raskemini loetav kui vaja.

Vooskeemi tüüp	Mida see näitab	Kõige paremini kasutatav
Protsessi vooskeem	Järjestikused sammud ühes protsessis	Algoritmi, funktsiooni loogika või äriprotseduuri dokumenteerimine
Süsteemi vooskeem	Kuidas andmed riist- ja tarkvarakomponentide kaudu liiguvad	Kõrgetasemeline arhitektuuri dokumentatsioon, pärandsüsteemide kaardistamine
Ujumisraja (valdkondadeülene) vooskeem	Vastutava isiku, meeskonna või süsteemi järgi rühmitatud sammud	Protsessid, mis hõlmavad mitut rolli või osakonda
Andmevoo diagramm (DFD)	Kuidas andmed protsesside, poodide ja väliste üksuste vahel liiguvad	Andmete teisenduste dokumenteerimine juhtimisloogika asemel
Töövoo diagramm	Ülesannete üleandmine ja kinnitusahelad äriprotsessis	Projektijuhtimine, kinnitamise töövood, piletite suunamine
UML-i tegevusdiagramm	Samaaegsed ja järjestikused tegevused formaalse UML-tähistusega	Objektorienteeritud tarkvara projekteerimisdokumentatsioon

Andmevoo diagramm vs vooskeem: mis vahe neil on?

See on üks levinumaid segadust tekitavaid punkte ja väärib otsest vastust. Vooskeem näitab juhtimisvoogu : sammude teostamise järjekorda ja tingimusi, mis määravad valitud tee. Andmevooskeem (DFD) näitab andmevoogu : kust andmed pärinevad, millised protsessid neid teisendavad, kus neid salvestatakse ja kuhu need lõpuks jõuavad, ilma et see tingimata näitaks toimingute järjestust või otsustusloogikat.

Vooskeem vastab küsimusele „mis juhtub, mis järjekorras, millistel tingimustel?“. Andmevooskeem vastab küsimusele „kust need andmed pärinevad, mis neid muudab ja kuhu need lõpuks jõuavad?“. Paljud reaalsed süsteemid saavad kasu mõlemast: vooskeemist töötlemisloogika dokumenteerimiseks ja DFD-st, mis dokumenteerib, kuidas teave selle loogika kaudu liigub.

Vooskeemi näited tarkvaraarenduses

Allolev Mermaid süntaks renderdub otse GitHubis, GitLabis, Notionis ja enamikes tänapäevastes dokumentatsiooniplatvormides, mistõttu on see standardne viis vooskeemide versioonimiseks koos koodiga, mitte eraldi staatiliste piltidena säilitamiseks.

Põhiprotsessi vooskeem

See vooskeem näitab kanoonilist mustrit, mida iga arendaja tunneb: alustamiseks terminaator, protsessietapp, kahe tulemusega otsustusromb ja koondumine tagasi ühte lõpp-punkti. Iga vooskeem, olenemata selle keerukusest, on üles ehitatud sama mustri korduvatest esinemisjuhtudest.

Vooskeem tsükliga

Vooskeemides kujutab tsükleid nool, mis viib tagasi varasemasse otsustuspunkti, mitte edasi. See on vooskeemi vaste for or while tsükkel koodis ja see on üks sissejuhatavate programmeerimiskursuste puhul enim testitud mustreid, „joonista vooskeem kolmest arvust suurima leidmiseks“ ja sarnased harjutused nõuavad peaaegu alati tsüklit või pesastatud otsustusstruktuuri.

Ujumisraja vooskeemi näide

Ujumisrajad (nimetatakse ka valdkondadevahelisteks vooskeemideks) rühmitavad protsessietapid nende teostaja järgi, muutes meeskondade või süsteemide vahelised üleandmised kohe nähtavaks. See vorming on standard selliste äriprotsesside dokumenteerimiseks, mis hõlmavad mitut osakonda või väliseid osapooli.

Kuidas luua tarkvaraarendusprotsessi vooskeem

1. samm: Määrake algus- ja lõpp-punkt. Igal vooskeemil on vaja täpselt ühte selget algus- ja lõpp-punkti. Kui dokumenteeritaval protsessil pole selget algus- ja lõpp-punkti, pole ulatus vooskeem efektiivseks koostamiseks veel piisavalt täpselt määratletud.

2. samm: Loetlege kõik sammud järjestuses. Kirjutage sammud enne sümbolite määramist lihtsas keeles välja. See eraldab loogilise definitsiooni skeemitööst ja muudab vigade leidmise lihtsamaks, puuduva sammu parandamine tekstiloendis on palju kiirem kui poolelioleval skeemil.

3. samm: Tuvastage iga otsustuspunkt. Käige läbi sammude loend ja märkige iga koht, kus järgmine toiming sõltub tingimusest. Iga otsustuspunkt muutub rombiks, millel on vähemalt kaks väljuvat teed, ja iga tee tuleb märgistada (Jah/Ei, Tõene/Vale või konkreetne tingimus).

4. samm: Määrake õiged sümbolid. Seoge iga samm selle sümboliga: ristkülikud tegevuste jaoks, rombid otsuste jaoks, rööpkülikud sisendi/väljundi jaoks ja ovaalid alguse ja lõpu jaoks. Sümbolite järjepidev kasutamine muudab vooskeemi loetavaks ka inimesele, kes pole konkreetse protsessiga tuttav.

5. samm: Ühendage suunanooltega. Igal sümbolil peaks olema selge sissetulev ja väljaminev ühendus (välja arvatud algus, millel pole sissetulevat ühendust, ja lõpp, millel pole väljaminevat ühendust). Nooled peaksid liikuma järjepidevas üldises suunas, tavaliselt ülevalt alla või vasakult paremale, et vältida visuaalset segadust.

6. samm: valideerige iga tee jälgimisega. Käige vooskeemis käsitsi läbi, järgides kõiki võimalikke teid algusest lõpuni. Veenduge, et iga otsustusharu viib kuhugi, et ükski tee ei satuks tupikusse ilma lõpp-punkti jõudmata ja et tsüklitel on määratletud väljumistingimus.

Tarkvaraarenduse vooskeemi tööriistad

Käsitsi loodud vooskeemide puhul on tarkvaraarenduse töövoogudes standardvarustuses mitu tööriista:

Mermaid ja PlantUML on diagrammide kui koodi tööriistad: vooskeem on defineeritud tekstina ja renderdatakse automaatselt, mis hoiab selle versioonikontrolli all koos dokumenteeritud lähtekoodiga. See on soovitatav lähenemisviis iga vooskeemi jaoks, mis dokumenteerib koodiloogikat, kuna seda saab uuendada samas commit'is kui koodimuudatust, mida see kirjeldab.

Lucidchart , Microsoft Visio ja draw.io on lohistamisliidestega üldotstarbelised diagrammide loomise tööriistad, mis sobivad äriprotsesside dokumenteerimiseks, esitluste ja versioonikontrollist väljaspool hallatavate diagrammide jaoks.

Valgetahvli tööriistad (füüsilised valgetahvlid, Miro, FigJam) sobivad koostööl põhinevateks disainiseanssideks, kus vooskeem on pigem arutelu käigus tekkiv tööartefakt kui püsiv dokument.

Nende kategooriate vaheline kompromiss on sünkroniseerimine: Lucidcharti või Visio käsitsi hallatavad diagrammid aeguvad alusprotsessi või koodi muutudes, kuna diagrammi värskendamine nõuab eraldi käsitsi tehtavat sammu, mida on lihtne unustada. Nii koodina loodud diagrammid kui ka automatiseeritud genereerimine lahendavad selle probleemi, sidudes diagrammi täpsuse automatiseeritud protsessiga, mitte inimmäluga.

Vooskeemide automaatne genereerimine olemasolevast koodist

Uue kujunduse vooskeemi käsitsi joonistamine toimib hästi. Olemasoleva, keeruka ja dokumenteerimata süsteemi vooskeemi käsitsi joonistamine ei ole skaleeritav ning tulemuseks on diagramm, mis on valmimise ajaks juba aegunud, kui aluskood dokumenteerimise käigus muutub.

Olemasolevate koodibaaside, eriti suurte või pärandsüsteemide puhul parsib automaatne vooskeemide genereerimine tegelikku lähtekoodi ja loob vooskeemi otse selle juhtimisvoost, iga if, iga tsükkel, iga funktsioonikõne renderdatakse vastava vooskeemi sümbolina, ilma et inimene peaks loogikat esmalt käsitsi jälgima.

See eristus on kõige olulisem pärandsüsteemide puhul. COBOL-programmis, mida on kahekümne aasta jooksul muutnud tosin arendajat, on kogunenud tingimusloogika, mida ükski inimene täielikult ei mõista. Selle programmi käsitsi joonistatud vooskeem nõuaks, et keegi loeks ja õigesti tõlgendaks iga rida – täpset probleemi, mida vooskeem peaks lahendama. Tegeliku lähtekoodi automaatne genereerimine annab täpse vooskeem, olenemata sellest, kui hästi keegi programmist praegu aru saab, sest see tuletatakse sellest, mida kood tegelikult teeb, mitte sellest, mida keegi arvab seda tegevat.

Kuidas SMART TS XL Genereerib teie koodibaasist vooskeeme

SMART TS XL loob vooskeeme, väljakutsegraafikuid ja sõltuvusdiagramme otse lähtekoodi analüüsist, COBOL-ist, JCL-ist, Java-st, Pythonist, RPG-st ja teistest keeltest, selle asemel, et arendajad peaksid neid käsitsi joonistama. See on põhimõtteliselt erinev lähenemisviis üldotstarbelistest diagrammide loomise tööriistadest nagu Lucidchart või Visio, mis pakuvad küll joonistusaluseid, kuid ei tea, mida teie kood tegelikult teeb.

Koodi visualiseerimise funktsioon analüüsib programmi juhtimisvoogu ja loob automaatselt täpse vooskeemi selle otsustusloogikast, harudest ja tsüklitest. Vananenud COBOL-programmi puhul, millel on aastakümnete pikkune tingimusloogika, tähendab see, et täieliku ja täpse vooskeemi saab genereerida hetkedega, selle asemel et nõuda päevi käsitsi koodi lugemiseks ja diagrammide joonistamiseks.

Kuna vooskeem genereeritakse otse lähtekoodi hetkeseisust, ei saa see sünkroonist välja minna nii nagu käsitsi hallatav diagramm. Iga kord, kui alusprogramm muutub, loob vooskeem uuesti genereerides ajakohastatud diagrammi, mis peegeldab tegelikku praegust loogikat, lahendades sünkroniseerimisprobleemi, mis mõjutab iga meeskonda, kes tugineb käsitsi koostatud protsessidokumentatsioonile.

Meeskondade jaoks, kes dokumenteerivad keerukaid süsteeme, laiendab rakenduste sõltuvuste kaardistamise võimalus seda ühe programmi vooskeemidest kaugemale, näidates, kuidas mitu programmi, töövoogu ja andmeallikat ühenduvad kogu rakenduste portfellis, vastates mitte ainult küsimusele „mida see programm teeb?“, vaid ka küsimusele „millega see programm ühendub ja mis sellega ühendub?“. Nagu koodi visualiseerimise tehnikate kontekstis kirjeldatud , lahendavad automaatselt genereeritud diagrammid aegumisprobleemi, mis muudab käsitsi hallatava dokumentatsiooni igas aktiivselt arendatud süsteemis ebausaldusväärseks.

Vooskeemid on suhtlusvahend, mitte ainult dokumentatsiooni artefakt

Vooskeemi väärtus ei seisne mitte diagrammis endas, vaid jagatud arusaamas, mille diagramm loob kõigi seda vaatavate vahel. Vooskeem, mis esindab protsessi täpselt, kuid millele keegi arenduse, koodi ülevaatamise või kasutuselevõtu ajal ei viita, on loonud dokumentatsiooni ilma väärtust loomata. Vooskeem, mida meeskond tegelikult kasutab ääremaa juhtumite arutamiseks, uue arendaja sisseelamiseks tundmatusse moodulisse või puuduva veakäsitlusharu tuvastamiseks, on oma töö teinud.

See praktiline väärtus sõltub vooskeemi ajakohasusest. Diagramm, mis joonistatakse esmase disaini käigus üks kord ja mida kunagi ei uuendata, muutub aktiivselt eksitavaks, kui kood sellest kõrvale kaldub, mis on hullem kui diagrammi puudumine üldse, sest see annab valekindlust. Olenemata sellest, kas tegemist on diagrammide kui koodi tavadega, mis hoiavad vooskeemi koodiga samas hoidlas, või automaatse genereerimisega, mis tuletab vooskeemi koodi tegelikust hetkeseisust, on diagrammi täpsuse säilitamise distsipliin see, mis eristab meeskonda tõeliselt abistavaid vooskeeme vooskeemidest, mis muutuvad aegunud artefaktideks, mida keegi ei usalda.