Dataflödesdiagram

Ett dataflödesdiagram (DFD) visar vilken data som rör sig genom ett system: var den kommer ifrån, vilka processer som tar emot och förändrar den, var den lagras och vart den skickas. Det visar däremot inte i vilken ordning saker händer, och inte vilka beslut som fattas. Det är den stora skillnaden mot ett flödesschema.

När du läst detta ska du kunna

• Känna igen och namnge de fyra delarna: extern entitet, process, datalager och dataflöde
• Rita ett kontextdiagram (nivå 0) och bryta ner det till nivå 1
• Kontrollera att nivåerna är i balans — samma flöden in och ut
• Förklara skillnaden mellan ett dataflödesdiagram och ett flödesschema

Vad används det till?

• Förstå ett system ur datans perspektiv — vad kommer in, vad går ut, vad sparas?
• Kravarbete — innan du vet hur systemet ska byggas, kan du rita vilken information det måste hantera
• Säkerhet och GDPR — var finns personuppgifterna, och vart skickas de? DFD är standardunderlaget i en hotmodellering
• Hitta luckor — en process som skickar ut data den aldrig fått in, eller ett datalager ingen läser från

Delarna och vad de heter

Det finns två vanliga ritsätt. Den här sidan använder Yourdon/DeMarco (cirklar för processer). Det andra, Gane-Sarson, visas längre ner — delarna är exakt desamma, bara formerna skiljer sig.

Fyra regler som gör ett DFD korrekt:

1. Allt dataflöde går genom en process. Två externa entiteter pratar aldrig direkt med varandra i diagrammet, och data hoppar aldrig direkt från ett datalager till ett annat.
2. Varje process har både in- och utflöde. En process som bara tar emot data är ett “svart hål”; en som bara skickar ut är ett “mirakel”.
3. Processer heter verb, flöden och lager heter substantiv. “Registrera order” och “orderuppgifter”, inte “Order” och “registrera”.
4. Inga beslut och ingen ordning. Pilarna säger vad som flyttas, inte när eller om.

Nivåer — från kontextdiagram till nivå 1

Ett DFD ritas i nivåer, lite som C4-modellens zoom i arkitekturdiagram:

• Kontextdiagram (nivå 0) — hela systemet som en enda process, med alla externa entiteter runt omkring. Inga datalager. Det visar systemets gräns: vad som kommer in och vad som går ut.
• Nivå 1 — den enda processen bryts upp i de viktigaste delprocesserna, numrerade 1, 2, 3. Nu syns datalagren.
• Nivå 2 och nedåt — en process från nivå 1 bryts ner i 1.1, 1.2… När processen är så enkel att den går att beskriva i några meningar kan du sluta.

Den viktigaste regeln mellan nivåerna är balans: flödena som går in i och ut ur systemet på nivå 0 måste finnas med, med samma namn, på nivå 1. Nya flöden får bara tillkomma inuti — mellan processer och datalager.

Exempel — en webbshops orderhantering

Kontextdiagram (nivå 0)

Hela orderhanteringen är en process. Runt den finns de fyra som utbyter data med den: kunden, betaltjänsten, lagret och fraktbolaget.

Nivå 1

Nu öppnar vi processen. Orderhanteringen består av tre delprocesser som delar på datalagret D1 Ordrar. Jämför med kontextdiagrammet: alla åtta flöden till och från de externa entiteterna finns kvar, med samma namn — diagrammen är i balans. Det som är nytt är flödena till och från datalagret.

Så här läser du det:

Lägg märke till vad diagrammet inte säger: det står inte att betalningen sker före leveransen, eller vad som händer om betalningen nekas. Det är inte en brist — det är inte DFD:ts jobb. Vill du visa det ritar du ett aktivitetsdiagram eller ett sekvensdiagram.

Från DFD till kod

Ett DFD är inte en ritning av klasser, men det mappar ofta naturligt: varje process blir en service med metoder, varje datalager en tabell (eller ett repository), och varje flöde en typ — en record eller DTO. Flödesnamnen i diagrammet är bra kandidater till typnamn:

// Dataflöden → typer
public record Beställning(int KundId, List<BeställdVara> Varor);
public record Orderbekräftelse(int OrderId, decimal Total);
public record Betalningsbegäran(int OrderId, decimal Belopp);

// Process 1 "Ta emot order": tar emot beställning, skickar ut orderbekräftelse och ny order
public class OrderMottagning
{
    private readonly IOrderRepository _ordrar;   // D1 Ordrar
    private readonly ILagerKlient _lager;        // extern entitet: Lager

    public OrderMottagning(IOrderRepository ordrar, ILagerKlient lager)
    {
        _ordrar = ordrar;
        _lager = lager;
    }

    public async Task<Orderbekräftelse> TaEmotAsync(Beställning beställning)
    {
        var saldo = await _lager.HämtaSaldoAsync(beställning.Varor);   // ← lagersaldo
        var order = Order.Skapa(beställning, saldo);
        await _ordrar.SparaAsync(order);                                 // → ny order (D1)
        return new Orderbekräftelse(order.Id, order.Total);              // → orderbekräftelse
    }
}

Gane-Sarson — det andra ritsättet

Gane-Sarson används mycket i systemutveckling och i verktyg för hotmodellering. Delarna och reglerna är desamma; bara formerna skiljer sig. Välj ett ritsätt och håll dig till det i hela dokumentationen.

DFD eller flödesschema?

De ser lika ut på håll — rutor och pilar — men de svarar på helt olika frågor.

Ett enkelt test: kan du läsa pilen som “och sedan…”? Då är det ett flödesschema. Kan du läsa den som “skickar orderuppgifter till…”? Då är det ett DFD.

När ska du välja ett dataflödesdiagram?

Vanliga misstag

• Ordning och beslut i diagrammet. En romb eller en pil som betyder “sedan” hör hemma i ett flödesschema. I ett DFD flyttar pilarna bara data.
• Entitet direkt till entitet. Om kunden skickar något direkt till fraktbolaget är det utanför ditt system — rita inte den pilen.
• Svarta hål och mirakel. En process med bara inflöde, eller bara utflöde, är nästan alltid ett tecken på att något saknas.
• Obalans mellan nivåer. Ett flöde som finns på nivå 1 men inte i kontextdiagrammet (eller tvärtom) betyder att något av diagrammen är fel.
• Onamngivna pilar. “Data” är inget namn. Skriv vilken data: “betalningsbegäran”, “plocklista”.
• Datalager i kontextdiagrammet. På nivå 0 är systemet en svart låda; dess datalager syns först på nivå 1.

Övning

Rita ett DFD för ett biblioteks utlåning:

1. Börja med ett kontextdiagram med den externa entiteten Låntagare (som skickar lånebegäran och får kvitto) och Påminnelsetjänst (som får försenade lån).
2. Bryt ner det till nivå 1 med processerna 1 Registrera lån, 2 Registrera återlämning och 3 Hitta försenade lån, och datalagren D1 Lån och D2 Exemplar.
3. Kontrollera balansen: finns alla flöden från kontextdiagrammet med på nivå 1, med samma namn?

TL;DR