Ett dataflödesdiagram (DFD) tillhör en av två kategorier: logiska eller fysiska. Lär dig mer om hur varje kategori används.
Vad är skillnaden mellan ett logiskt och ett fysiskt DFD?
Ett logiskt DFD fokuserar på företaget och dess affärsverksamhet, medan ett fysiskt DFD handlar om hur ett system implementeras. Även om alla dataflödesdiagram beskriver informationsflödet för en process eller ett system, beskriver alltså logiska diagram ”vad” medan fysiska diagram beskriver ”hur”. Det motsvarar två olika perspektiv på samma informationsflöde, och båda är avsedda att visualisera och förbättra systemet. Ett logiskt DFD beskriver de affärshändelser som äger rum och de data som krävs för varje händelse. Det ger en stadig grund för ett fysiskt DFD, som beskriver hur själva datasystemet kommer att fungera – till exempel maskinvara, programvara, pappersdokument och inblandade personer. Tillsammans beskriver ett logiskt och ett fysiskt DFD hela det aktuella tillståndet och modellerar det nya tillstånd som ska övervägas och sedan implementeras.
Logiskt DFD
Fysiskt DFD
Syfte och fördelar med varje kategori
Genom att börja med ett aktuellt logiskt DFD kartlägger du flödet av affärshändelser efter hand som de inträffar, vilket kan belysa eventuella brister eller ineffektivitet. Kanske vet du redan vilken typ av funktionalitet som du vill lägga till, och ett aktuellt logiskt DFD hjälper dig då att identifiera de processteg som kan behöva tas bort eller ändras. Precis som alla andra diagram bör ett logiskt DFD vara tillräckligt detaljerat för att det ska gå att agera utifrån det. Beroende på omfattning kan det ta tid och verka enformigt att producera ett logiskt DFD som beskriver nuläget, men det kan vara väl investerat arbete.
En annan fördel med ett logiskt DFD är att det tenderar att vara mer lättförståeligt för användare som saknar tekniska kunskaper. Det kommer förmodligen att vara meningsfullt för de personer som deltar i affärsverksamheten. Diagrammet fungerar som ett bra verktyg för att samarbeta och kommunicera om förbättringar av information och funktioner utan att man ännu behöver fundera så mycket på ”hur”.Det fungerar som en bro mellan affärsbehoven och de tekniska kraven. Arbetet med att kartlägga det aktuella logiska flödet ger alla inblandade en djupare förståelse och avslöjar felaktiga antaganden, missförstånd eller brister. Att ta fram logiska modeller minskar risken för att missa affärskrav – misstag som annars skulle visa sig senare i processen och orsaka förseningar och omarbetningar.
I nästa steg, när det finns en gedigen förståelse av dagens affärsverksamhet, kan du modellera ett bättre sätt med ett logiskt DFD för det nya tillståndet, som visar nya funktioner utifrån vad som har framkommit i affärsanalysen. Detta nya logiska DFD modellerar vilka dataflöden som krävs för att skapa de bättre funktionerna, oavsett teknisk lösning eller hur systemet kommer att implementeras.
När ett nytt logiskt DFD har ritats kan det användas för att ta reda på vad som är det bästa sättet att implementera affärsaktiviteterna i ett uppgraderat system. Det blir grunden för ett nytt fysiskt DFD som beskriver den fysiska tillämpningen av enheter, programvara, filer och medarbetare som möjliggör affärsprocesserna. Med andra ord kan man säga att ett fysiskt DFD motsvarar metoden för att uppfylla företagets behov. Det är det ”hur” som driver ”vad”. Med ett fysiskt DFD lägger man grunden till en implementationsplan som syftar till att tillhandahålla ny programvara, maskinvara, personal eller andra fysiska delar som behövs för att driva affärsprocessen.
Ett exempel på logisk kontra fysisk dataflödesanalys
Låt säga att HR-avdelningen använder föråldrade arbetsmetoder och ett krångligt system för att spåra arbetssökande. I stället för att direkt sätta igång med att jämföra olika nya programvaror börjar du med att kartlägga det aktuella logiska dataflödet. Du beskriver de affärsaktiviteter som äger rum, till exempel åtgärder som vidtas för att skriva en jobbannons, lägga ut den, registrera ansökningar i företagets register eller databas, informera rekryterande chefer, uppdatera filerna, spåra processteg, kontakta sökande och så vidare. Allt det här görs ur affärsverksamhetens perspektiv, inte tekniska perspektiv eller andra aspekter av ”hur”. Det beskriver det aktuella dataflödet och ger grunden för att kommunicera och samarbeta om förbättrad funktionalitet för att utföra de åtgärder som krävs för att hitta de bästa sökande. Sedan kartlägger du ett tänkbart nytt logiskt flöde. Det kan till exempel vara att skicka notiser med aktuell information till rekryterande chefer, vilket håller dem bättre informerade. Kanske kan de lättare komma åt cv:n och jämförelser av de slutliga kandidaternas meriter. Detta nya logiska DFD utgör ett diskussionsunderlag för hur man bäst tillämpar förbättrade funktioner för programvara, maskinvara, arkiveringssystem och personal – alltsammans kan visualiseras i ett fysiskt DFD. Diagrammet kan användas för att utvärdera programvarulösningar och andra delar av tillämpningen i syfte att se vilka som bäst uppfyller affärsbehoven. Du kan till exempel visa hur olika programvaruplattformar skulle skilja sig åt i olika versioner av det fysiska DFD:et, vilket hjälper dig att hitta den bästa lösningen.
Vad som skiljer sig åt mellan logiska och fysiska DFD
Dataflödesdiagram består av fyra olika element: externa enheter, processer, datalager och dataflöden. Men elementen motsvarar olika perspektiv i logiska respektive fysiska DFD.
Exempel: I ett logiskt DFD är processerna affärsverksamhet, medan processerna i ett fysiskt DFD består av programvara, manuella rutiner eller andra sätt att bearbeta information. I ett logiskt DFD är datalagren samlingar av information, oavsett hur de lagras. I ett fysiskt DFD utgörs datalager av databaser, datafiler eller pappersdokument.
Så används diagrammen inom olika områden
Logiska och fysiska DFD inom programvaruteknik: DFD har sitt ursprung i programvaru- och systemutveckling. Ett logiskt DFD kan fånga upp de nuvarande och nödvändiga aktiviteter som krävs för en process. Ett nytt logiskt DFD modellerar en ny uppsättning aktiviteter och funktioner. Ett aktuellt fysiskt DFD visar nuvarande programvara, maskinvara, databaser och personal som behövs för att utföra aktiviteterna, och ett nytt fysiskt DFD modellerar en ny implementering av systemet. Den här analysen kan ge ett bättre sätt att utveckla den faktiska kod som uppfyller kraven.
Inom affärsanalys: Ett logiskt DFD kan hjälpa till att avslöja affärskrav som annars inte upptäcks förrän sent i processen, vilket orsakar förseningar och omarbetningar.Det fungerar också som ett tydligt kommunikationsverktyg med icke-tekniska personer som är involverade i affärsverksamheten, både för det nuvarande informationsflödet och den föreslagna nya metoden. Det fysiska DFD:et ger då upphov till systemets ”hur” för att uppfylla kraven.
Inom strukturerad analys: I klassisk, strukturerad top-down-analys ritar man ett logiskt DFD över ett aktuellt system för att beskriva dess nuvarande tillstånd, och modellerar sedan ett förbättrat system i en nytt logiskt DFD. Fysiska top-down-DFD ritas sedan för att illustrera den fysiska lösningen för programvara, enheter och andra systemdelar. I händelsedriven, strukturerad bottom-up-analys fastställer ett kontextdiagram (ett DFD på nivå 0) projektets omfattning, och efterföljande nivåer bryter ner det i delprocesser. Vi anger därefter systemhändelser som kräver ett svar, och ritar händelse-DFD för att beskriva hur varje händelse hanteras. Dessa händelse-DFD kan sedan infogas i ett systemdiagram.
Inom kontor och administration: Ett logiskt DFD används för att skildra de affärsåtgärder som äger rum för att verksamheten på ett kontor ska fungera. Ett nytt logiskt DFD kan därefter modellera bättre funktionalitet med kontorets information, till exempel personal- eller kunddata samt beställningar. Det lägger grunden till att förstå hur det ska åstadkommas, vilket visas i ett fysiskt DFD som beskriver hur man bäst implementerar ny programvara, nya enheter, nya datafiler eller databaser samt nya medarbetare.
Inom hälso- och sjukvård: Ett aktuellt fysiskt DFD kan illustrera det aktuella dataflödessystemet, till exempel för patientinformation. Det kan användas för att rita ett aktuellt logiskt DFD som visar datafunktionerna med undantag för ”hur”. Dessa DFD bidrar till att skapa en tydlig förståelse av dagens brister och kraven på ett nytt system. Det i sin tur utgör grunden för ett nytt logiskt DFD och därefter ett nytt fysiskt DFD som beskriver ny programvara, nya enheter, nya databaser och andra fysiska objekt.
En snabb, allmän introduktion till DFD
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. Konceptet med strukturerad design blev populärt inom programutveckling, och användningen av DFD-metoden ökade samtidigt. Dataflödesdiagram kan vara allt från en enkel 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. De använder fastställda symbolsystem för att beskriva de fyra olika elementen: externa enheter, processer, datalager och dataflöden. De vanligaste symbolsystemen är uppkallade efter sina skapare: Yourdon-Coad, Yourdon-DeMarco och Gane-Sarson.
DFD-nivåer numreras med 0, 1 och 2 – ibland kan de gå ända upp till nivå 3 eller högre. Vilken detaljnivå som krävs beror på omfattningen av det som du försöker uppnå. Ett DFD på nivå 0 kallas även ett kontextdiagram. Det utgör en grundläggande översikt över hela det system eller den process som analyseras eller modelleras. Ett DFD på nivå 1 ger en mer detaljerad uppdelning av de olika delarna av kontextdiagrammet. De huvudsakliga funktioner som systemet utför lyfts fram när processerna delas upp i sina delprocesser från kontextdiagrammets högre abstraktionsnivå. Ett DFD på 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.
Även om DFD används i processmodellering av system utförs datamodellering ofta med enhetsrelationsdiagram (ERD) för att visa vilka data som finns i systemet. För objektmodellering beskriver Unified Modeling Language (UML) bäst systemets ”vad”- och ”varför”-logik. DFD skiljer sig också från flödesscheman, som visar de steg som ingår i en process – vanligtvis med enkla rutor och pilar. Flödesscheman visar inte indata eller utdata från externa källor, och de visar inte heller den väg som informationen tar när processen utförs.
Vill du veta mer? Här finns en detaljerad översiktsartikel om dataflödesdiagram.
