Flowdiagram for softwareudviklingsproces: Symboler, typer og eksempler

Et flowdiagram for en softwareudviklingsproces konverterer en række trin, beslutninger og resultater til et diagram, som alle kan læse på få sekunder. Hvor et tekstafsnit kræver omhyggelig læsning for at forstå rækkefølgen af ​​operationer og de betingelser, der ændrer stien, viser et flowdiagram det rumligt: ​​start her, gør dette, tjek den betingelse, forgren dig til venstre eller højre, fortsæt til slutningen. Denne rumlige repræsentation er grunden til, at flowdiagrammer fortsat er et af de mest anvendte diagramværktøjer inden for softwareudvikling, mere end halvfjerds år efter, at de først blev introduceret.

Denne guide dækker alt, hvad der er nødvendigt for at læse, oprette og anvende flowdiagrammer i en softwareudviklingskontekst: standardsymbolerne og deres betydning, de forskellige typer flowdiagrammer og hvornår de skal bruges, eksempler i et format, du kan kopiere og gengive med det samme, og hvordan flowdiagrammer forbinder sig til den faktiske kode, de repræsenterer, herunder hvordan denne forbindelse kan genereres automatisk i stedet for at blive tegnet i hånden.

Hvad er et flowdiagram i softwareudvikling?

Et flowdiagram er et diagram, der repræsenterer en proces, algoritme eller arbejdsgang ved hjælp af standardiserede symboler forbundet med pile, der angiver flowretningen. I softwareudvikling kortlægger flowdiagrammer logikken i et program eller en proces: rækkefølgen af ​​operationer, de punkter, hvor programmet træffer beslutninger, og de forskellige veje, udførelsen kan tage afhængigt af disse beslutninger.

Flowcharts stammer fra 1920'erne inden for industriel ingeniørvidenskab, hvor de blev brugt til at dokumentere fremstillingsprocesser. Teknikken blev formaliseret til databehandling i 1940'erne og 1950'erne, og da struktureret programmering blev standardpraksis i 1970'erne, var flowcharts blevet en central del af dokumentation af softwaredesign. I dag er flowcharts stadig i aktiv brug til algoritmedesign, onboarding-dokumentation, kortlægning af forretningsprocesser og kommunikation af logik til ikke-tekniske interessenter, selvom mere specialiserede diagramtyper (UML, sekvensdiagrammer, tilstandsdiagrammer) har overtaget nogle af de roller, som flowcharts oprindeligt udfyldte.

Hvad er forskellen mellem et flowdiagram og et procesflowdiagram?

Disse udtryk bruges ofte i flæng, og i de fleste sammenhænge er det harmløst. Hvor der nogle gange drages en sondring: et flowdiagram repræsenterer typisk logikken i en enkelt algoritme eller et program, beslutninger, løkker, forgreninger i kode. Et procesflowdiagram (eller procesflowdiagram) repræsenterer oftere en forretningsproces, rækkefølgen af ​​aktiviteter på tværs af personer, afdelinger eller systemer, ofte uden den finkornede beslutningslogik fra et flowdiagram på kodeniveau. I praksis deles symbolerne og konventionerne mellem begge, og det udtryk, du bruger, bestemmes i høj grad af din målgruppe og branchekonventioner snarere end en streng teknisk grænse.

Flowchart-symboler: Den komplette reference

Symboler for flowdiagrammer er standardiserede, så enhver læser, uanset sprog eller baggrund, kan fortolke et flowdiagram korrekt. Tabellen nedenfor dækker alle symboler, der bruges i standard flowdiagrammer for softwareudvikling:

Symbol	Shape	Navn	Betydning
⬭	Oval / Afrundet rektangel	Terminator (Start/Slut)	Markerer begyndelsen eller slutningen af ​​processen
▭	rektangel	Proces	Repræsenterer et enkelt trin, en handling eller en operation
◇	Diamant	Beslutning	Et forgreningspunkt med to eller flere mulige udfald (Ja/Nej, Sandt/Falsk)
▱	parallelogram	Input / Output	Repræsenterer data, der kommer ind i eller forlader processen
⬡	Hexagon	Forberedelse	Repræsenterer et opsætningstrin, såsom initialisering af en løkketæller
▭ (med dobbelt kant)	Foruddefineret proces	Et kald til en separat, allerede defineret proces eller subrutine
⬠	Dokument	Repræsenterer et udskrevet eller genereret dokument
○	Lille cirkel	Stik	Forbinder to punkter i flowdiagrammet, ofte brugt til at undgå krydsende linjer
▽	Trekant (peger nedad)	Flet	Kombinerer flere stier til én
△	Trekant (peger opad)	Uddrag	Opdeler én sti i flere
→	Arrow	Flowledning	Angiver retningen af ​​procesflowet
⬢	Off-page-forbindelse	Angiver, at flowet fortsætter på en anden side

De to symboler, som enhver læser skal genkende med det samme, er rektanglet (et procestrin) og diamanten (et beslutningspunkt med flere udgange). Disse to alene dækker størstedelen af ​​indholdet af et flowdiagram. Den ovale/afrundede terminator, der markerer start og slut, fuldender det minimale ordforråd, der er nødvendigt for at læse de fleste flowdiagrammer korrekt.

Typer af flowdiagrammer brugt i softwareudvikling

Forskellige typer flowdiagrammer tjener forskellige formål. Hvis man vælger den forkerte type til situationen, får man et diagram, der er teknisk korrekt, men sværere at læse end nødvendigt.

Flowcharttype	Hvad det viser	Bedst brugt til
Process flowchart	Sekventielle trin i en enkelt proces	Dokumentation af en algoritme, en funktions logik eller en forretningsprocedure
Systemflowdiagram	Hvordan data bevæger sig gennem hardware- og softwarekomponenter	Dokumentation af arkitektur på højt niveau, kortlægning af ældre systemer
Flowchart for svømmebane (tværfunktionelt)	Trin grupperet efter den ansvarlige person, team eller system	Processer, der spænder over flere roller eller afdelinger
Dataflowdiagram (DFD)	Hvordan data flyttes mellem processer, butikker og eksterne enheder	Dokumentation af datatransformationer i stedet for kontrollogik
Workflow diagram	Opgaveoverdragelser og godkendelseskæder i en forretningsproces	Projektstyring, godkendelsesworkflows, ticketrouting
UML-aktivitetsdiagram	Samtidige og sekventielle aktiviteter med formel UML-notation	Dokumentation af objektorienteret softwaredesign

Dataflowdiagram vs. flowdiagram: Hvad er forskellen?

Dette er et af de mest almindelige forvirringspunkter, og det fortjener et direkte svar. Et flowdiagram viser kontrolflow : den rækkefølge, hvori trin udføres, og de betingelser, der bestemmer, hvilken vej der tages. Et dataflowdiagram (DFD) viser dataflow : hvor data stammer fra, hvilke processer der transformerer dem, hvor de gemmes, og hvor de i sidste ende går hen, uden nødvendigvis at vise den sekventielle rækkefølge af operationer eller beslutningslogik.

Et flowdiagram svarer på "hvad sker der, i hvilken rækkefølge, under hvilke betingelser?". Et dataflowdiagram svarer på "hvor kommer disse data fra, hvad ændrer dem, og hvor ender de?". Mange virkelige systemer drager fordel af begge dele: et flowdiagram til at dokumentere behandlingslogikken og et DFD til at dokumentere, hvordan information bevæger sig gennem denne logik.

Eksempler på flowdiagrammer i softwareudvikling

Mermaid-syntaksen nedenfor gengives direkte i GitHub, GitLab, Notion og de fleste moderne dokumentationsplatforme, hvilket gør det til standardmåden at holde flowdiagrammer versioneret sammen med kode i stedet for at vedligeholdes som separate statiske billeder.

Grundlæggende procesflowdiagram

Dette flowdiagram viser det kanoniske mønster, som enhver udvikler genkender: en terminator til at starte, et procestrin, en beslutningsdiamant med to resultater og konvergens tilbage til et enkelt slutpunkt. Hvert flowdiagram, uanset hvor komplekst det er, er bygget op af gentagne forekomster af det samme mønster.

Flowchart med en løkke

Løkker i flowdiagrammer er repræsenteret af en pil, der vender tilbage til et tidligere beslutningspunkt i stedet for at fortsætte fremad. Dette er flowdiagrammets svar på en for or while En løkke i kode, og det er et af de mønstre, der oftest testes i introduktionskurser i programmering, "tegn et flowdiagram for at finde det største af tre tal" og lignende øvelser kræver næsten altid en løkke eller en indlejret beslutningsstruktur.

Eksempel på flowdiagram for svømmebane

Swimlanes (også kaldet tværfunktionelle flowdiagrammer) grupperer procestrin efter, hvem der udfører dem, hvilket gør overdragelser mellem teams eller systemer øjeblikkeligt synlige. Dette format er standarden for dokumentation af forretningsprocesser, der involverer flere afdelinger eller eksterne parter.

Sådan opretter du et flowdiagram for softwareudviklingsprocesser

Trin 1: Definer start- og slutpunkter. Hvert flowdiagram skal have præcis ét klart startpunkt og et eller flere klare slutpunkter. Hvis den proces, du dokumenterer, ikke har en tydelig start og slut, er omfanget endnu ikke veldefineret nok til at kunne lave et effektivt flowdiagram.

Trin 2: Angiv hvert trin i rækkefølge. Skriv trinnene ned i et letforståeligt sprog, før du tildeler symboler. Dette adskiller den logiske definition fra diagramarbejdet og gør det lettere at opdage fejl. Det er meget hurtigere at rette et manglende trin i en tekstliste end i et halvtegnet diagram.

Trin 3: Identificer hvert beslutningspunkt. Gennemgå trinlisten og marker hvert sted, hvor den næste handling afhænger af en betingelse. Hvert beslutningspunkt bliver en diamant med mindst to udgående stier, og hver sti skal mærkes (Ja/Nej, Sandt/Falsk eller den specifikke betingelse).

Trin 4: Tildel de korrekte symboler. Knyt hvert trin til dets symbol: rektangler for handlinger, diamanter for beslutninger, parallelogrammer for input/output og ovaler for start og slut. Konsekvent symbolbrug er det, der gør et flowdiagram læseligt for en person, der ikke er bekendt med den specifikke proces.

Trin 5: Forbind med retningspile. Hvert symbol skal have en tydelig indgående og udgående forbindelse (undtagen starten, som ikke har nogen indgående forbindelse, og slutningen, som ikke har nogen udgående forbindelse). Pilene skal gå i en ensartet generel retning, typisk fra top til bund eller fra venstre til højre, for at undgå visuel forvirring.

Trin 6: Valider ved at spore hver sti. Gennemgå flowdiagrammet manuelt, og følg alle mulige stier fra start til slut. Bekræft, at hver beslutningsgren fører et sted hen, at ingen stier ender i blindgyder uden at nå en slutterminator, og at løkker har en defineret slutbetingelse.

Flowchartværktøjer til softwareudvikling

Til manuelt oprettede flowdiagrammer er flere værktøjer standard i softwareudviklingsworkflows:

Mermaid og PlantUML er diagram-som-kode-værktøjer: Flowchartet defineres som tekst og gengives automatisk, hvilket holder det versionskontrolleret sammen med den kildekode, det dokumenterer. Dette er den anbefalede tilgang til ethvert flowchart, der dokumenterer kodelogik, fordi det kan opdateres i samme commit som den kodeændring, det beskriver.

Lucidchart , Microsoft Visio og draw.io er generelle diagramværktøjer med træk-og-slip-grænseflader, der er velegnede til dokumentation af forretningsprocesser, præsentationer og diagrammer, der vedligeholdes uden for versionskontrol.

Whiteboardværktøjer (fysiske whiteboards, Miro, FigJam) er velegnede til kollaborative designsessioner, hvor flowdiagrammet er et fungerende artefakt under en diskussion snarere end et permanent dokument.

Afvejningen mellem disse kategorier er synkronisering: manuelt vedligeholdte diagrammer i Lucidchart eller Visio forældes, når den underliggende proces eller kode ændres, fordi opdatering af diagrammet kræver et separat, manuelt trin, der er let at glemme. Diagrammer-som-kode og automatiseret generering løser begge dette ved at knytte diagrammets nøjagtighed til en automatiseret proces snarere end menneskelig hukommelse.

Generering af flowdiagrammer automatisk fra eksisterende kode

Manuel tegning af et flowdiagram til et nyt design fungerer godt. Manuel tegning af et flowdiagram for at dokumentere et eksisterende, komplekst, udokumenteret system skalerer ikke, og det producerer et diagram, der allerede er forældet, når det er færdigt, hvis den underliggende kode ændres under dokumentationsarbejdet.

For eksisterende kodebaser, især store eller ældre systemer, analyserer automatiseret generering af flowdiagrammer den faktiske kildekode og producerer flowdiagrammet direkte fra dets kontrolflow, hver gang if, hvert loop, hvert funktionskald gengives som det tilsvarende flowdiagramsymbol, uden at et menneske først skal spore logikken manuelt.

Denne sondring er vigtigst for ældre systemer. Et COBOL-program, der er blevet modificeret af et dusin udviklere over tyve år, har akkumuleret betinget logik, som ingen enkelt person fuldt ud forstår. Et manuelt tegnet flowdiagram af det program ville kræve, at nogen læser og korrekt fortolker hver linje først, det præcise problem, som flowdiagrammet skal løse. Automatiseret generering fra den faktiske kildekode producerer et nøjagtigt flowdiagram, uanset hvor godt nogen i øjeblikket forstår programmet, fordi det er afledt af, hvad koden rent faktisk gør, snarere end hvad nogen tror, ​​den gør.

Hvordan SMART TS XL Genererer flowdiagrammer fra din kodebase

SMART TS XL producerer flowdiagrammer, kaldgrafer og afhængighedsdiagrammer direkte fra kildekodeanalyse, COBOL, JCL, Java, Python, RPG og andre sprog, i stedet for at kræve, at udviklere tegner dem manuelt. Dette er en fundamentalt anderledes tilgang end generelle diagramværktøjer som Lucidchart eller Visio, der leverer tegneunderlag, men ikke har nogen bevidsthed om, hvad din kode rent faktisk gør.

Kodevisualiseringsfunktionen analyserer et programs kontrolflow og producerer automatisk et nøjagtigt flowdiagram over dets beslutningslogik, forgreninger og løkker. For et ældre COBOL-program med årtiers akkumuleret betinget logik betyder det, at et komplet og præcist flowdiagram kan genereres på få øjeblikke i stedet for at kræve dages manuel kodelæsning og diagramtegning.

Da flowdiagrammet genereres direkte fra kildekoden, kan det ikke komme ud af synkronisering, sådan som et manuelt vedligeholdt diagram gør. Hver gang det underliggende program ændres, producerer regenerering af flowdiagrammet et opdateret diagram, der afspejler den faktiske, aktuelle logik, og løser dermed synkroniseringsproblemet, der påvirker alle teams, der er afhængige af manuelt tegnet procesdokumentation.

For teams, der dokumenterer komplekse systemer, udvider applikationsafhængighedskortlægningsfunktionen dette ud over flowdiagrammer for enkeltprogrammer for at vise, hvordan flere programmer, jobstrømme og datakilder forbinder på tværs af en hel applikationsportefølje, og besvarer ikke blot "hvad gør dette program?", men "hvad forbinder dette program til, og hvad forbinder til det?". Som beskrevet i forbindelse med kodevisualiseringsteknikker løser automatisk genererede diagrammer problemet med forældet dokumentation, der gør manuelt vedligeholdt dokumentation upålidelig i ethvert aktivt udviklet system.

Flowcharts er et kommunikationsværktøj, ikke blot et dokumentationsartefak

Værdien af ​​et flowdiagram ligger ikke i selve diagrammet, men i den fælles forståelse, diagrammet skaber mellem alle, der ser på det. Et flowdiagram, der præcist repræsenterer en proces, men som ingen refererer til under udvikling, kodegennemgang eller onboarding, har produceret dokumentation uden at skabe værdi. Et flowdiagram, som teamet rent faktisk bruger til at diskutere edge cases, til at onboarde en ny udvikler til et ukendt modul eller til at identificere en manglende fejlhåndteringsgren, har gjort sit job.

Den praktiske værdi afhænger af, at flowdiagrammet forbliver aktuelt. Et diagram, der tegnes én gang under det indledende design og aldrig opdateres, bliver aktivt misvisende, når koden afviger fra det. Det er værre end slet ikke at have et diagram, fordi det giver falsk tillid. Uanset om det er gennem diagram-som-kode-praksisser, der holder flowdiagrammet i samme arkiv som koden, eller gennem automatiseret generering, der udleder flowdiagrammet fra kodens faktiske nuværende tilstand, er disciplinen med at holde diagrammet nøjagtigt det, der adskiller flowdiagrammer, der virkelig hjælper et team, fra flowdiagrammer, der bliver forældede artefakter, som ingen stoler på.