Diagramy przepływu danych

Diagram przepływu danych (Data Flow Diagram, w skrócie DFD) to metoda pozwalająca na modelowanie systemu informacyjnego ze względu na aspekt funkcjonalny. W porównaniu do diagramów hierarchii funkcji, DFD jest modelem dokładniejszym, który oprócz funkcji, ukazuje także dane – przepływające w określonym ładzie pomiędzy funkcjami, w celu stworzenia oczekiwanych rezultatów. Diagramy przepływu danych zawierają cztery kategorie pojęciowe: proces, obiekt zewnętrzny, magazyn danych, przepływ danych. Mała liczba elementów może być ułatwieniem w stosowaniu modelu, jednakże skuteczne posługiwanie się tym modelem wymaga znajomości zasad biznesowych, bez których stworzony opis dziedziny przedmiotowej może być niekompletny lub niespójny. Odpowiednio zaprojektowany diagram przepływu danych może być podstawą działań projektowych, czy wdrożeniowych, związanych z cyklem życia systemu. Sam model przedstawiany jest w formie grafu, który w zależności od notacji rysowania, korzysta z różnych elementów graficznych do prezentowania poszczególnych komponentów. Najpopularniejszymi notacjami są metodyka Yourdon-DeMarco, metodyka Gene-Sarsona lub metodyka SSADM (P. Polak 2015, s.18; K. Sacha 2012, s.82, Wrycza i in. 2019, s. 326-327).

Elementy diagramów przepływu danych

Wśród elementów diagramów przepływu danych wymienić można: procesy, przepływy danych, obiekty zewnętrzne oraz magazyny danych.

Procesy

Procesy wyrażają działania realizowane przez system informacyjny i stanowią odpowiednik funkcji, które występują w diagramach hierarchii funkcji. W przypadku opisywania modelu związanego z tym samym systemem informacyjnym, wykonanym przy pomocy diagramów przepływu danych i diagramów hierarchii funkcji, mogą wystąpić podobieństwa lub identyczne nazewnictwo procesów i funkcji, w szczególności tych elementarnych. Procesy, które występują w DFD realizują zarówno funkcje proste, jak i złożone. Zadaniem procesu jest przekształcenie danych wejściowych na dane wyjściowe, co z kolei powoduje, że każdy proces musi posiadać przynajmniej jedno wejście, a także jedno wyjście. Dodatkowo dane, które nie znalazły się w wejściu do procesu lub nie mogły zostać przetworzone, nie mogą być zawarte w wyjściu z procesu. Elementem opisu, którego nie widać na diagramie przepływu danych jest specyfika przekształcania danych wejściowych, w dane wyjściowe. Ten brak można uzupełnić poprzez dekompozycję złożonego procesu, a następnie przedstawienie struktury wewnętrznej przy pomocy bardziej szczegółowego diagramu przepływu danych lub przy pomocy opisu działań procesu prostego w języku naturalnym, w pseudokodzie, w postaci graficznej lub przy użyciu notacji matematycznej (P. Polak 2015, s. 18; K. Sacha 2012, s. 83).

Przepływy danych

Przepływy danych prezentują transfery danych pomiędzy procesami, obiektami zewnętrznymi i magazynami danych. Przedstawiane są przy pomocy strzałek, które wskazują kierunek przepływu. Nazwa elementu wskazuje dane, które stanowią ten przepływ w zależności od specyfiki czy źródła, którego dotyczą. W przypadku danych ogólnych może to być przykładowo adres klienta czy średnia ocen studenta, gdy dane związane są z nazwą dokumentu, który zawiera te dane to może to być na przykład faktura sprzedaży czy zamówienie, a w przypadku obiektu charakteryzowanego przez te dane przykładem może być produkt czy nowy klient. Każdy z przepływów danych musi zaczynać się lub kończyć na procesie. Dodatkowo niektóre z metod modelowania nie dopuszczają także możliwości bezpośredniego powiązania dwóch procesów za pomocą przepływu danych (P. Polak 2015, s.20; K. Sacha 2012, s.83-84).

Obiekty zewnętrzne

Obiekt zewnętrzny (terminator) tak jak w przypadku przepływu danych może reprezentować różne źródła danych. Może przedstawiać osoby (np. klientów, studentów, pracowników), jednostki organizacyjne (np. biuro regionalne, dział finansowy przedsiębiorstwa), organizację (np. dostawca, bank), a także inne systemy informacyjne (np. system magazynowy, system finansowy), które znajdują się poza obszarem modelowanego systemu, lecz wstępują w interakcję z systemem. Obiekt zewnętrzny odpowiedzialny jest za dostarczanie danych do modelowanego systemu lub za otrzymywanie danych z systemu (P. Polak 2015, s.20, K. Sacha 2012, s. 83-84).

Magazyny danych

Magazyn danych (skład/składnica danych) prezentuje dane, które są przechowywane w systemie w celu późniejszego wykorzystania. Nazewnictwo każdego z magazynów danych związane jest z obiektem, którego informacje przechowywane są w systemie. Składnice danych mogą dotyczyć osób (np. klienci, studenci, pracownicy przedsiębiorstwa), rzeczy (np. produkty, materiały), jednostek organizacyjnych (np. katedry, wydziały, działy) lub obiektów niematerialnych (np. płatności, zamówienia). Nazwy magazynów prezentowane są w liczbie mnogiej. Wszystkie magazyny muszą posiadać co najmniej jedno wejście bądź wyjście. Nie ma żadnego sensu występowanie magazynu, który nie otrzymuje, wiec i nie przechowuje jakichkolwiek danych, jak również nie ma sensu utrzymywać magazynu, który gromadzi dane do niczego nieprzydatne (P. Polak 2015, s. 21).

Tworzenie diagramów przepływu danych

Składa się z przygotowania trzech występujących po sobie diagramów. Pierwszym z nich jest diagram kontekstowy, który definiuje oraz prezentuje granice i zakres systemu. Występuje w formie specjalnego graficznego schematu, ukazującego przepływy danych. Składa się z jednego procesu reprezentującego cały modelowany system, wszystkich obiektów zewnętrznych oraz z przepływów danych pomiędzy obiektami zewnętrznymi a systemem. Na diagramie kontekstowym każdy z przepływów danych ukazuje wszystkie wejścia i wyjścia, związane z informacjami systemu. Dotyczą one zwykle dokumentacji (papierowej czy elektronicznej) wymienianej pomiędzy systemem a otoczeniem. Celem tego diagramu jest zaprezentowanie powiązań między systemem a środowiskiem zewnętrznym.

Diagram systemowy (diagram zerowy) pokazuje ogólną perspektywę całego systemu. Ten diagram można uznać za dekompozycję diagramu kontekstowego, który przedstawia główne funkcje systemu. Składa się z tych samych obiektów zewnętrznych, wraz z wejściami i wyjściami do nich, co w diagramie kontekstowym. Różnicą jest proces prezentujący system, który jest opisany bardziej szczegółowo. W celu poprawnego opracowania diagramu systemowego należy zacząć od zidentyfikowania wszystkich ogólnych procesów realizowanych przez system, a także od zidentyfikowania magazynów danych. Następnie powinno się określić źródła danych (obiekty zewnętrzne i magazyny danych) dla poszczególnych procesów, a także połączyć je za pomocą przepływów danych. Kolejnym krokiem jest określenie wszystkich wyjść pomiędzy procesami, a ich odbiorcami (obiekty zewnętrzne i magazyny danych) oraz połączyć procesy z odbiorcami za pomocą przepływów. Należy też pamiętać o ponumerowaniu wszystkich procesów, jednak kolejność jest bez znaczenia.

Diagramy szczegółowe to diagramy niższych poziomów, które tworzy się, gdy system jest rozbudowany. W sytuacji gdy system jest niewielki, nie ma potrzeby tworzenia dodatkowych diagramów i jeden diagram systemowy wystarcza w zupełności. W przypadku tworzenia diagramu szczegółowego każdy z procesów dekomponowany jest na oddzielnym diagramie niższego poziomu. Przykładowo proces numer 1 dekomponowany jest na diagramie numer 1 i sytuacja wygląda analogicznie do pozostałych procesów, dekomponowanych w ramach diagramu systemowego (D. Olczyk 2010, s.98; P. Polak 2015, s.21-23).

Zasady sporządzania diagramów przepływu danych

Wśród podstawowych zasad sporządzania DFD wymienić można między innymi (J.D. Mejor 2012, s.106-108):

• Obiekty zewnętrzne (terminatory) nie mogą komunikować się ze sobą bezpośrednio. Komunikacja z obiektami zewnętrznymi jest możliwa tylko przy pomocy pośredniczenia przez system.
• Magazyny danych nie mogą komunikować się miedzy sobą. Ruch danych (zapisywanie lub odczytywanie) w magazynach odbywa się tylko za pomocą działań procesów. Dodatkowo dane zawarte w magazynach nie są spójne i każdy z magazynów zawiera inny typ danych.
• Obiekty zewnętrzne nie mogą kontaktować się z magazynami danych. Dane zostają pobrane z magazynu za pomocą procesów. Dodatkowo zakres danych jest tak obszerny, że nie ma możliwości zapisania ich w jednym magazynie. Możliwe jest buforowanie danych wejściowych i tworzenie tak zwanych magazynów tymczasowych.
• Brak występowania tak zwanych czarnych dziur, czyli procesów, które pobierając dane od przepływów danych nie tworzą nic na wyjściu. W przypadku zauważenia czarnej dziury w systemie, należy zastanowić się czy dany proces nie jest magazynem gromadzącym dane.
• Brak występowania tak zwanych magicznych procesów, czyli takich, które tworzą dane bez pobierania danych wejściowych.
• Każdy element diagramu przepływu danych powinien posiadać własną nazwę. Powinno stosować się zasady, że procesy podaje się w czasowniku w formie czynnej lub w dopełnieniu, przepływy danych nazywane są adekwatnie do przenoszonych danych, a obiekty zewnętrzne prezentowane rzeczownikami w mianowniku. Dodatkowo nazewnictwo powinno być uniwersalne.
• Diagramy przepływów danych nie powinny być nadmiernie złożone. Stworzony diagram powinien mieścić się na kartce w formacie A4, a także powinien zawierać do sześciu procesów i koniecznych obiektów zewnętrznych, przepływów i magazynów.

Bibliografia

• Mejor J.D. (2012), Przepływ danych w placówce informacyjnej call center, „Zagadnienia informacji naukowej, Instytut Informacji Naukowej i Studiów Bibliologicznych Uniwersytetu Warszawskiego”, Tom 50, Nr 2(100), Warszawa
• Odlanicka-Poczobutt M., Kulińska E. (2015), Zastosowanie diagramu przepływu danych w analizie systemowej procesu realizacji zamówienia klienta Interco, [w:] Innowacje w zarządzaniu i inżynierii produkcji. T. 1, R. Knosala (red.), Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole
• Olczyk D. (2010), Modelowanie strukturalne: definicje, notacje, techniki i narzędzia, „Zeszyty Naukowe Warszawskiej Wyższej Szkoły Informatyki”, Nr 4, Warszawa
• Polak P. (2015), Wprowadzenie do projektowania systemu, [w:] Wstęp do informatyki gospodarczej. Zajęcia laboratoryjne, K. Polańska (red.), Oficyna wydawnicza Szkoła Główna Handlowa, Warszawa
• Sacha K. (2012), Inżynieria oprogramowania, Wydawnictwo Naukowe PWN, Warszawa
• Wrycza S., Maślankowski J. (red.) (2019), Informatyka ekonomiczna. Teoria i zastosowania, Wydawnictwo Naukowe PWN, Warszawa

Autor: Mateusz Jeliński