Logiskt eller fysiskt dataflödesdiagram

Ett logiskt DFD fokuserar på affärs- och affärsverksamheten, medan ett fysiskt DFD tittar på hur ett system implementeras. Så även om alla dataflödesdiagram beskriver informationsflödet för en process eller ett system så beskriver logiska diagram ”vad” och fysiska diagram ”hur”. Det är två olika perspektiv på samma informationsflöde, och båda har utformats för 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 det fysiska DFD:et, som beskriver hur alla delar av datasystemet kommer att fungera – till exempel maskinvara, programvara, pappersdokument och inblandade personer. Tillsammans beskriver det logiska och det fysiska DFD:et helt och hållet det aktuella tillståndet och modellerar det nya tillståndet som ska övervägas och sedan implementeras.

Logiskt DFD

Fysiskt DFD

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 ineffektiviteter. Eller så känner du redan till vilken typ av funktionalitet du vill lägga till, och det aktuella logiska DFD:et hjälper till att identifiera processteg som kan behöva tas bort eller ändras.Precis som alla andra diagram bör det logiska DFD:et vara tillräckligt detaljerat för att vara handlingsbart. Beroende på omfattning kan det ta tid och verka tråkigt att producera ett logiskt DFD som beskriver nuläget, men det kan vara välinvesterat arbete.

En annan fördel med logiska DFD är att de tenderar att vara mer lättförståeliga för icke-tekniker. De kommer antagligen att vara meningsfulla för de personer som arbetar i affärsverksamheten. De fungerar som ett bra verktyg för att samarbeta och kommunicera om förbättring av information och funktioner, utan att ännu bry sig om ”hur”.De 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, programvaror, filer och personal som möjliggör affärsprocesserna. Man kan på så sätt säga att det fysiska DFD:et blir metoden för att uppfylla företagets behov. Det är hur:et som driver vad:et. Det fysiska DFD:et ger därefter 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.

Låt oss säga att HR-avdelningen har en föråldrad arbetsmetod 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 annonser, registrera ansökningar i företagets register eller databas, informera rekryterande chefer, uppdatera filerna, spåra processteg, kontakta sökande och så vidare. Allt detta görs ur affärsverksamhetens perspektiv, inte tekniska perspektiv eller andra delar 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. Du kartlägger sedan 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. Det kan ge dem enklare tillgång till cv:n och jämförelser av slutkandidaternas kvalifikationer. 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 – och allt kan visualiseras i ett fysiskt DFD. Det 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 till att hitta den bästa lösningen.

Dataflödesdiagram består av fyra olika element: externa enheter, processer, datalager och dataflöden. Men elementen representerar olika perspektiv i logiska respektive fysiska DFD.

Exempel: I logiska DFD är processerna affärsverksamhet, medan processerna i fysiska DFD består av program, manuella rutiner eller andra sätt att behandla information. I logiska DFD är datalagren samlingar av information, oavsett hur de lagras. I fysiska DFD utgörs datalager av databaser, datafiler eller pappersdokument.

Logiska och fysiska DFD inom programvaruteknik: DFD har sitt ursprung i programvaru- och systemutveckling. Ett logiskt DFD kan fånga aktuella 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 den nuvarande programvaran, maskinvaran, databaserna och personalen som behövs för att utföra aktiviteterna, och ett nytt fysiskt DFD modellerar en ny systemimplementering. Denna analys kan ge ett bättre sätt att utveckla den faktiska kod som löser 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 det föreslagna nya sättet. Det fysiska DFD beskriver sedan systemets ”hur” och blir underlag för kraven.

Inom strukturerad analys: I klassisk, strukturerad top-down-analys ritar man ett logiskt DFD av ett nuvarande 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 (DFD-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, som personal- eller kunddata och beställningar. Det utgör basen för att förstå hur det ska åstadkommas och visas i ett fysiskt DFD som beskriver hur ny programvara ska implementeras och nya enheter, datafiler eller databaser samt de medarbetare som krävs.

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 nya programvaror, enheter, databaser och andra fysiska objekt.

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.

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

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. 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.

Ä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.