Vad är ett dataflödesdiagram?

Ett dataflödesdiagram (DFD) illustrerar informationsflödet i en process eller ett system. Diagrammet innehåller fördefinierade symboler som rektanglar, cirklar och pilar tillsammans med korta textetiketter för att visa datainmatningar, -utmatningar, -lagringspunkter och vägarna mellan olika mål. Dataflödesdiagram kan vara allt från en enkel, rent av handritad processöversikt till ett detaljerat DFD i flera nivåer som gräver sig allt djupare ner i hur data hanteras. De kan användas för att analysera ett befintligt system, eller för att modellera ett nytt. Som alla bra diagram kan ett DFD ofta visuellt ”säga” saker som skulle vara svåra att förklara i ord, och de fungerar med både tekniska och icke-tekniska målgrupper – från programmerare till VD. Det är anledningen till att DFD fortfarande är så populära. Även om de fungerar bra för programvara och system som bygger på dataflöden är de inte lika effektiva för att presentera program eller system som är interaktiva, databasorienterade eller i realtid.

Dataflödesdiagram blev populära i slutet av 1970-talet och härrör från boken Structured Design av datorpionjärerna Ed Yourdon och Larry Constantine. De baserade den på beräkningsmodellerna för ”grafer över dataflöden” framtagna av David Martin och Gerald Estrin. Konceptet med strukturerad design blev populärt inom programutveckling, och användningen av DFD-metoden tog fart. Metoden blev mer populär inom näringslivet, där den användes för affärsanalys, än i akademiska kretsar.

Det fanns två relaterade koncept som också bidrog:

• Objektorienterad analys och design (OOAD) som presenterades av Ed Yourdon och Peter Coad som ett sätt att designa en applikation eller ett system.
• Structured Systems Analysis and Design Method (SSADM), en variant av vattenfallsmodellen, för att analysera och designa informationssystem. Denna rigorösa dokumentationsmetod står i kontrast med moderna, agila metoder som Scrum och Dynamic Systems Development Method (DSDM).

Tre andra experter som bidrog till utvecklingen inom DFD-metodiken var Tom DeMarco, Chris Gane och Trish Sarson. De samarbetade sinsemellan i olika kombinationer och blev de som definierade de symboler och den notation som används för dataflödesdiagram.

Tre vanliga symbolsystem har fått namn efter sina skapare:

• Yourdon-Coad
• Yourdon-DeMarco
• Gane-Sarson

En viktig skillnad mellan deras symboler är att Yourdon-Coad och Yourdon-DeMarco använder cirklar för processer, medan Gane-Sarson använder rektanglar med rundade hörn. Det finns även andra symbolvarianter som används, så det viktiga är att vara tydlig och konsekvent med vilka former och notationer som används vid kommunikation och samarbete med andra.

Oavsett vilken konvention av DFD-regler eller -riktlinjer som används, beskriver symbolerna de fyra komponenter som finns i dataflödesdiagram:

1. Extern entitet:

   Ett utanförliggande system som skickar eller tar emot data och kommunicerar med systemet som visas i diagrammet. Externa entiteter är källorna till och målen för för den information som kommer in i eller lämnar systemet. Det kan handla om en utomstående organisation eller person, ett datorsystem eller ett affärssystem. Externa entiteter kallas även avslutare, källor och mottagare, eller aktörer. De ritas vanligtvis i kanten av diagrammet.

2. Process:

   Varje process som ändrar data och producerar utdata. Processen kan utföra beräkningar eller sortera data baserat på logik, eller styra dataflödet baserat på affärsregler. En kort etikett används för att beskriva processen, till exempel ”Skicka betalning”.

3. Datalager:

   Filer eller arkiv som lagrar information för senare användning, till exempel en databastabell eller ett medlemsformulär. Varje datalager får en enkel etikett, till exempel ”Beställningar”.

4. Dataflöde:

   Den väg som data tar mellan de externa entiteterna, processerna och datalagren. Dataflödet beskriver gränssnittet mellan övriga komponenter, och visas med pilar som vanligtvis får en etikett med ett kort datanamn, till exempel ”Betalningsuppgifter”.

Notation	Yourdon-Coad	Gane-Sarson
Extern entitet
Process
Datalager
Dataflöde

Vill du veta mer? Här finns en omfattande beskrivning av diagramsymboler och notation samt hur de används.

• Varje process ska ha minst en inmatning och en utmatning.
• Varje datalager ska ha minst ett ingående dataflöde och ett utgående dataflöde.
• Data som lagras i ett system måste genomgå en process.
• Alla processer i ett DFD leder till en annan process eller ett datalager.

Ett dataflödesdiagram kan gå in i allt finare detaljer genom att man använder nivåer och lager, och zoomar in på en viss del. DFD-nivåer numreras 0, 1 och 2 – ibland kan de även gå till nivå 3 eller ännu högre. Vilken detaljnivå som krävs beror på omfattningen av det som du försöker uppnå.

• DFD-nivå 0 kallas även kontextdiagram. Det är en grundläggande översikt över hela det system eller den process som analyseras eller modelleras. Det är utformat för att ge en överblick och visar systemet som en enda process på hög abstraktionsnivå och dess relation till externa entiteter. Kontextdiagrammet ska enkelt kunna förstås av en bred publik, som intressenter, affärsanalytiker, dataanalytiker och utvecklare. 

• DFD-nivå 1 ger en mer detaljerad uppdelning av olika delar av kontextdiagrammet. De huvudsakliga funktioner som systemet utför lyfts fram när processerna delas upp i sina underprocesser från att ha haft en hög abstraktionsnivå i kontextdiagrammet. 

• DFD-nivå 2 går sedan ytterligare ett steg djupare i delar av nivå 1. Det kan krävas mer text för att ge tillräckligt detaljerad information om systemets funktionalitet.

​

• Det är möjligt att gå vidare till nivå 3, 4 och ännu längre, men det är ovanligt att man går längre än till nivå 3. Det kan skapa en grad av komplexitet som gör det svårt att kommunicera, jämföra eller modellera effektivt.

Genom att använda DFD-lager kan de underliggande nivåerna kapslas in i diagrammet, vilket ger ett renare utseende med enkel åtkomst till detaljerna.

Med tillräckligt detaljerad information i DFD:et kan utvecklare och designers använda det för att skriva pseudokod – en kombination av klartext och programmeringskod. Pseudokoden underlättar programmeringen av den faktiska programkoden.

Dataflödesdiagram lämpar sig väl för att analysera eller modellera olika typer av system inom olika områden.

DFD i programvaruutveckling: Det var här som dataflödesdiagrammen huvudsakligen började användas på 1970-talet. Ett DFD kan ge den tekniska utvecklingen fokus, genom analysarbete som förberedelse inför själva kodningen.

DFD i affärsanalys: Affärsanalytiker använder DFD för att analysera befintliga system och hitta ineffektiviteter. Genom att dokumentera processer i diagram kan man förtydliga steg som kanske annars missas eller inte helt förstås.

DFD i BPR (Business Process Re-engineering):  Ett DFD kan användas för att modellera ett bättre och effektivare dataflöde genom en affärsprocess. BPR lanserades under 1990-talet som ett sätt att hjälpa organisationer att sänka sina driftskostnader, förbättra kundservicen och bli mer konkurrenskraftiga.

DFD i agil utveckling: Ett DFD kan användas för att visualisera och förstå affärskrav och tekniska krav samt för att planera kommande steg. Det kan vara ett enkelt men kraftfullt verktyg för kommunikation och samarbete för att fokusera en snabb utveckling.

DFD i systemstrukturer: Alla system eller processer kan analyseras med allt större detaljrikedom i syfte att förbättra dem, ur såväl ett tekniskt som ett icke-tekniskt perspektiv.

Ett DFD illustrerar hur data flödar genom ett system, medan UML är ett modellspråk som används inom objektorienterad programvarudesign för att ge en mer detaljerad vy. Ett DFD kan fortfarande ge en bra startpunkt, men för att utveckla systemet i praktiken använder utvecklare ofta UML-diagram – som klassdiagram och strukturdiagram – för att få den exakthet som krävs.

Det här är de två typer av dataflödesdiagram som finns. Ett logiskt DFD visualiserar det dataflöde som krävs för att ett företag ska fungera. Det fokuserar på företaget och på informationen som krävs, inte på hur systemet fungerar (eller är tänkt fungera). Ett fysiskt DFD visar däremot hur systemet de facto är implementerat (eller hur det kommer att implementeras). Exempel: I ett logiskt DFD är processerna företagsaktiviteter, medan de i ett fysiskt DFD är programmatiska och manuella procedurer.

Vill du veta mer? Mer information finns i Logical vs. Physical Data Flow Diagram (Logiskt eller fysiskt DFD).

Du kan skapa ditt eget DFD online med Lucidchart. Använd våra DFD-exempel och vår specialanpassade notation för att visuellt representera flödet av information genom ditt system. Vår skapare av dataflödesdiagram är enkel men ändå kraftfull. Kom igång med en mall och använd våra former för att anpassa dina processer, datalager, dataflöden och externa entiteter.