Przykład budowy modelu DFD. Metodologie modelowania domeny Diagramowanie przepływu danych dfd

Diagramy przepływu danych (GRD) są głównym sposobem modelowania wymagań funkcjonalnych dla projektowanego systemu. Za ich pomocą wymagania są reprezentowane jako hierarchia komponentów funkcjonalnych (procesów) połączonych przepływami danych. główny cel taka reprezentacja ma zademonstrować, w jaki sposób każdy proces przekształca swoje dane wejściowe w wyniki, a także ujawnić relacje między tymi procesami.

Do budowy diagramów EGO używa się dwóch różnych notacji, odpowiadających metodom Jordana i Gein-Sersona, które różnią się nieco graficznym przedstawieniem symboli. Ponadto przy konstruowaniu przykładów będzie używany zapis Hein-Sersona. Konstruowanie diagramów FDT wiąże się głównie z rozwojem systemów oprogramowania, a do tego celu pierwotnie opracowano notację EDF.

Zgodnie z tymi metodami model systemu jest definiowany jako hierarchia przepływów danych opisująca asynchroniczny proces transformacji informacji od jej wejścia do systemu do wydania użytkownikowi. Diagramy wyższych poziomów hierarchii (diagramy kontekstowe) definiują główne procesy lub podsystemy z zewnętrznymi wejściami i wyjściami. Są one szczegółowo opisane za pomocą diagramów niższego poziomu. Ta dekompozycja trwa dalej, tworząc wielopoziomową hierarchię diagramów, aż do osiągnięcia takiego poziomu dekompozycji, na którym procesy stają się elementarne, tak że niemożliwe jest ich dalsze uszczegółowienie.

Źródła informacji (podmioty zewnętrzne) generować przepływy informacji (strumienie danych), które przenoszą informacje do podsystemów lub procesów. Te z kolei przekształcają informacje i generują nowe przepływy, które przekazują informacje do innych procesów lub podsystemów, magazynów danych lub podmiotów zewnętrznych – konsumentów informacji.

Głównymi składnikami diagramów OGB są:

• podmioty zewnętrzne;
• systemy i podsystemy;
• urządzenia do przechowywania danych;
• strumienie danych.

Podmioty zewnętrzne to obiekty materialne lub indywidualny, który jest źródłem lub odbiorcą informacji, np. klientem, personelem, dostawcą, klientem, magazynem. Zdefiniowanie jakiegoś obiektu lub systemu jako podmiotu zewnętrznego wskazuje, że znajduje się on poza granicami analizowanego systemu. W trakcie procesu analizy niektóre podmioty zewnętrzne można w razie potrzeby przenieść wewnątrz diagramu analizowanego systemu lub odwrotnie, część procesów można przenieść poza diagram i przedstawić jako podmiot zewnętrzny.

Podmiot zewnętrzny jest oznaczony kwadratem (ryc. 5.12), umieszczonym niejako nad schematem i rzucającym cień, aby symbol można było odróżnić od innych oznaczeń. Budując model złożonego systemu oprogramowania, można go przedstawić w najogólniejszej postaci na tzw. diagramie kontekstowym jako jeden

system jako całość lub może być rozłożony na kilka podsystemów (rys. 5.13).

Ryż. 5.12.

Identyfikator

licznik dziennika

Pole NazwaPola

fizyczny

realizacja

Ryż. 5.13. Diagram kontekstowy

Numer podsystemu służy do jego identyfikacji. W polu nazwy wpisywana jest nazwa podsystemu w postaci zdania z tematem oraz odpowiadającymi im definicjami i dodatkami.

Proces jest transformacją strumienie wejściowe dane na wyjściu zgodnie z określonym algorytmem. Fizycznie proces może być realizowany na różne sposoby: może to być pododdział (dział) organizacji wykonujący określone przetwarzanie dokumentów wejściowych i wydania raportów, program, zaimplementowane sprzętowo urządzenie fizyczne itp. Proces na schemacie jest przedstawiony jako prostokąt z zaokrąglonymi rogami (ryc. 5.14).

Pole liczbowe

Pole nazwy Pole

fizyczny

realizacja

Ryż. 5.14. Obraz procesu

Numer procesu służy do jego identyfikacji. W polu nazwy wpisuje się nazwę procesu w postaci zdania z aktywnym jednoznacznym czasownikiem w formie nieokreślonej („oblicz”, „sprawdź”, „oblicz”, „utwórz” itp.), a następnie rzeczownik w bierniku (ryc. 5.14). Użycie czasowników typu „proces”, „modernizować” czy „edytować” wskazuje na brak zrozumienia tego procesu i wymaga dalszej analizy. Informacje w polu implementacji fizycznej wskazują, który dział, program lub urządzenie obsługuje proces.

Przechowywanie danych- jest to abstrakcyjne urządzenie do przechowywania informacji, które można w dowolnym momencie umieścić w napędzie i po pewnym czasie usunąć, a metody wstawiania i ekstrakcji mogą być dowolne. Urządzenie do przechowywania danych (storage) może być fizycznie zaimplementowane w postaci tabeli w pamięci RAM, pliku na dysku magnetycznym, szafki na akta itp. Urządzenie do przechowywania danych na schemacie jest identyfikowane za pomocą litery AND i dowolnej liczby. Nazwę napędu wybiera się ze względu na największą zawartość informacyjną dla projektanta (rys. 5.15).

identyfikacja

Pole nazwy

Ryż. 5.15. Obraz dysku danych

Przechowywanie danych jest generalnie prototypem przyszłej bazy danych, opis przechowywanych w niej danych powinien być powiązany z modelem informacyjnym (NIM). Przepływ danych jest reprezentowany przez strzałkę i opisuje przepływ informacji od źródła do odbiorcy. W rzeczywistości mogą to być informacje przesyłane kablem między dwoma urządzeniami, listy wysyłane pocztą, dyskietki przeniesione z jednego komputera na drugi itp. Każdy strumień ma nazwę, która odzwierciedla jego zawartość (rysunek 5.16).

Generuj deklaracje podatku dochodowego

raportowanie

Raportowanie w dniu

podatek dochodowy

Ryż. 5.16.

Łącza na diagramach PBP mogą być dzielone (rozwidlone) na części, a nazwę każdego wynikowego segmentu można zmienić w taki sposób, aby pokazać rozkład danych niesionych przez jakiś strumień (rys. 5.17). Strzałki można łączyć (łączyć), tworząc złożone obiekty. Np. w celu utworzenia adresu podatnika niezbędne jest posiadanie danych o jego elementach (kod pocztowy, miasto, ulica, numer domu i numer mieszkania).

Zapisz adres podatnika

Dział księgowości podatników

Ryż. 5.17.

Wykorzystując diagramy GPW do modelowania wymagań funkcjonalnych dla system oprogramowania, dla jasności ich zrozumienia i wygody projektanta budują hierarchię diagramów. W takim przypadku wskazane jest przestrzeganie następujących zaleceń:

• umieść na każdym schemacie od 3 do 6-7 procesów;
• nie zaśmiecaj diagramów szczegółami, które są nieistotne na tym poziomie;
• dekompozycja strumieni danych do przeprowadzenia równolegle z dekompozycją procesów;
• wybieraj jasne, znaczące nazwy procesów i wątków, unikając skrótów.

Pierwszym krokiem w budowaniu hierarchii diagramów przepływu danych jest zbudowanie diagramów kontekstowych, które pokazują, w jaki sposób projektowany system będzie współdziałał z użytkownikami i innymi systemami zewnętrznymi (nieco analogiczne do przypadków użycia w obiektach podejście zorientowane). Przy projektowaniu stosunkowo prostych systemów wystarczy jeden diagram kontekstowy, który ma topologię gwiazdy, w centrum której znajduje się główny proces związany ze źródłami i odbiornikami informacji.

Dla systemów złożonych budowana jest hierarchia diagramów kontekstowych, która determinuje współdziałanie głównych podsystemów funkcjonalnych projektowanego systemu zarówno między sobą, jak iz zewnętrznymi przepływami danych wejściowych i wyjściowych oraz obiektami zewnętrznymi. Jednocześnie diagram kontekstowy najwyższego poziomu zawiera zestaw podsystemów połączonych przepływami danych. Diagramy kontekstowe następnego poziomu szczegółowo opisują zawartość i strukturę podsystemów.

Po zbudowaniu diagramów kontekstowych należy sprawdzić w powstałym modelu kompletność danych wyjściowych o obiektach systemu oraz izolację obiektów (brak powiązań informacyjnych z innymi obiektami). Dla każdego podsystemu obecnego na diagramach kontekstowych jest szczegółowo opisany za pomocą diagramów BDT. Każde zdarzenie jest reprezentowane jako proces z odpowiednimi strumieniami wejściowymi i wyjściowymi, akumulatorami danych, podmiotami zewnętrznymi, linkami do innych procesów w celu opisania powiązań między tym procesem a jego środowiskiem.

Z kolei każdy proces na diagramie YGO można uszczegółowić za pomocą ERE lub (jeśli proces jest elementarny) specyfikacji. Kiedy należy przestrzegać szczegółów następujące zasady:

• reguła równoważenia, co oznacza, że ​​podczas uszczegóławiania podsystemu można używać tylko tych komponentów (podsystemów, procesów, podmiotów zewnętrznych, dysków danych), z którymi ma on połączenie na schemacie nadrzędnym;
• reguła numeracji, która mówi, że przy wyszczególnianiu procesów należy wspierać ich hierarchiczną numerację.

Specyfikacja procesu powinien sformułować swoje główne funkcje w taki sposób, aby w przyszłości specjalista realizujący projekt mógł je wykonać lub opracować odpowiedni program. Specyfikacja jest ostatnim szczytem hierarchii.O/7/). Decyzję o zakończeniu procesu uszczegółowiania i wykorzystaniu specyfikacji podejmuje analityk w oparciu o następujące kryteria:

• proces ma niewielką ilość danych wejściowych i wyjściowych (2-3 wątki);
• możliwość opisania transformacji danych przez proces w postaci algorytm sekwencyjny;
• wykonanie w procesie pojedynczej funkcji logicznej przekształcania informacji wejściowych w informacje wyjściowe;
• możliwość opisania logiki procesu za pomocą specyfikacji małej objętości (nie więcej niż 20-30 wierszy).

Specyfikacje muszą spełniać następujące wymagania:

• musi istnieć jedna (i tylko jedna) specyfikacja dla każdego procesu niskopoziomowego;
• specyfikacja musi określać, w jaki sposób strumienie wejściowe są konwertowane na strumienie wyjściowe;
• nie ma potrzeby (przynajmniej na etapie tworzenia wymagań) określenia sposobu realizacji tej transformacji;
• specyfikacja powinna dążyć do ograniczenia redundancji: nie należy przedefiniowywać tego, co zostało już zdefiniowane na schemacie;
• zestaw konstrukcji do specyfikacji budynku powinien być prosty i zrozumiały.

W rzeczywistości specyfikacja jest opisem algorytmów dla zadań wykonywanych przez procesy. Specyfikacje zawierają numer i (lub) nazwę procesu, listy danych wejściowych i wyjściowych oraz treść (opis) procesu, czyli specyfikację algorytmu lub operacji, która przekształca strumienie danych wejściowych w wyjściowe. Znanych jest wiele różnych metod opisu korpusu procesu. Języki powiązane z tymi metodami mogą obejmować ustrukturyzowany język naturalny lub pseudokod, a także języki projektowania wizualnego.

Ustrukturyzowany język naturalny jest używany do czytelnego, wystarczająco rygorystycznego opisu specyfikacji procesu. Taki język składa się z podzbioru słów zorganizowanych w określone struktury logiczne, wyrażenia arytmetyczne i diagramy. Struktury sterujące języka obejmują konstrukcję sekwencyjną, konstrukcję wyboru i iterację (pętlę).

W przypadku używania strukturalnego języka naturalnego przyjmuje się następujące konwencje:

• logika procesu jest wyrażona jako kombinacja konstruktów sekwencyjnych, konstruktów selekcji i iteracji;
• czasowniki powinny być aktywne, jednoznaczne i skoncentrowane na działaniu docelowym (na przykład „wypełnij”, „oblicz”, „wyodrębnij”, a nie „modernizuj”, „przetwórz”);
• logika procesu musi być wyrażona jasno i jednoznacznie.

Budując hierarchię diagramów przepływu danych, przejdź

uszczegółowienie procesów następuje dopiero po zdefiniowaniu struktur danych opisujących zawartość wszystkich strumieni i magazynów danych. Struktury danych mogą zawierać alternatywy, warunki warunkowe i iteracje. Alternatywa oznacza, że ​​jeden z wymienionych elementów może być uwzględniony w konstrukcji. Wystąpienie warunkowe wskazuje, że dany komponent może nie występować w konstrukcji. Iteracja polega na wystąpieniu dowolnej liczby elementów z określonego zakresu.

Dla każdego elementu można określić jego typ (ciągły lub dyskretny). W przypadku danych ciągłych można określić jednostkę miary, zakres wartości, precyzję reprezentacji i formę fizycznego kodowania. W przypadku danych dyskretnych można określić tabelę prawidłowych wartości.

Po zbudowaniu kompletnego modelu systemu należy go zweryfikować (sprawdzić pod kątem kompletności i spójności). W kompletnym modelu wszystkie jego obiekty (podsystemy, procesy, przepływy danych) muszą być szczegółowo opisane i uszczegółowione. W spójnym modelu wszystkie strumienie danych i magazyny danych muszą być zgodne z regułą przechowywania informacji: wszystkie dane, które gdzieś trafiają, muszą zostać odczytane, a wszystkie odczytane dane muszą zostać zapisane.

Podstawą tej metodologii graficznego modelowania systemów informatycznych jest specjalna technologia konstruowania diagramów przepływu danych DFD. W opracowaniu metodologii DFD brało udział wielu analityków, wśród których należy wymienić E. Yordona (E. Yourdona). Jest autorem jednej z pierwszych notacji graficznych DFD. Obecnie najbardziej powszechna jest tak zwana notacja Gene-Sarson, której główne elementy zostaną omówione w tym rozdziale.

Model systemu w kontekście DFD jest reprezentowany jako pewien model informacyjny, którego głównymi składnikami są różne przepływy danych, które przenoszą informacje z jednego podsystemu do drugiego. Każdy z podsystemów wykonuje określone przekształcenia wejściowego strumienia danych i przekazuje wyniki przetwarzania informacji w postaci strumieni danych do innych podsystemów.

Główne elementy diagramów przepływu danych to:

Podmioty zewnętrzne

Dyski lub przechowywanie danych

Procesy

Strumienie danych

Systemy/podsystemy

Podmiot zewnętrzny to materialny obiekt lub osoba, która może działać jako źródło lub odbiorca informacji. Definicja jakiegoś obiektu lub systemu jako bytu zewnętrznego nie jest ściśle ustalona. Chociaż podmiot zewnętrzny znajduje się poza granicami rozpatrywanego systemu, w trakcie dalszej analizy niektóre podmioty zewnętrzne mogą zostać przeniesione wewnątrz diagramu modelu systemu. Z drugiej strony poszczególne procesy można wyjmować z diagramu i przedstawiać jako podmioty zewnętrzne. Przykładami podmiotów zewnętrznych są: klienci organizacji, klienci, personel, dostawcy.

Podmiot zewnętrzny jest oznaczony prostokątem z cieniem (ryc. 2.15), wewnątrz którego wskazana jest jego nazwa. W takim przypadku zaleca się użycie rzeczownika w mianowniku jako nazwy. Czasami podmiot zewnętrzny jest również nazywany terminatorem.

Ryż. 2.15. Obraz podmiotu zewnętrznego na diagramie przepływu danych

Proces to zestaw operacji służących do konwersji strumieni danych wejściowych na strumienie wyjściowe zgodnie z określonym algorytmem lub regułą. Chociaż proces może być fizycznie zaimplementowany na różne sposoby, najczęściej chodzi o implementację oprogramowania procesu. Proces na diagramie przepływu danych jest reprezentowany przez zaokrąglony prostokąt (rysunek 2.16) podzielony poziomymi liniami na trzy sekcje lub pola. Pole numeru procesu służy do identyfikacji tego ostatniego. Środkowe pole wskazuje nazwę procesu. Jako nazwę zaleca się użycie czasownika w formie nieokreślonej z niezbędnymi dodatkami. Dolne pole zawiera wskazanie, w jaki sposób proces jest fizycznie zaimplementowany.

Ryż. 2.16. Obraz procesu na diagramie przepływu danych

Ryż. 2.17. Obraz podsystemu na diagramie przepływu danych

Model informacyjny systemu zbudowany jest jako diagram hierarchiczny w postaci tzw. diagramu kontekstowego, na którym model wyjściowy jest sekwencyjnie reprezentowany jako model podsystemów odpowiednich procesów transformacji danych. W takim przypadku podsystem lub system na diagramie kontekstowym DFD jest przedstawiony w taki sam sposób, jak proces - prostokąt z zaokrąglonymi wierzchołkami (ryc. 2.17).

Urządzenie pamięci masowej lub pamięć masowa to abstrakcyjne urządzenie lub metoda przechowywania informacji, które są przenoszone między procesami. Zakłada się, że dane można umieścić na dysku w dowolnym momencie i odzyskać po pewnym czasie, a fizyczne metody umieszczania i pobierania danych mogą być dowolne. Nośnik danych może być fizycznie zaimplementowany na różne sposoby, ale najczęściej zakłada się, że jest zaimplementowany w: w formie elektronicznej na nośnikach magnetycznych. Akumulator danych na schemacie przepływu danych jest przedstawiony jako prostokąt z dwoma polami (rys. 2.18). Pierwsze pole służy do określenia numeru lub identyfikatora dysku, który zaczyna się na literę „D”. Drugie pole służy do określenia nazwy. W takim przypadku zaleca się użycie rzeczownika jako nazwy napędu, który charakteryzuje sposób przechowywania odpowiednich informacji.

Ryż. 2.18. Obraz dysku na diagramie przepływu danych

Wreszcie przepływ danych określa jakościowy charakter informacji przesyłanych przez pewne połączenie od źródła do odbiorcy. Rzeczywisty strumień danych może być przesyłany przez sieć między dwoma komputerami lub w inny sposób, który umożliwia wyodrębnienie i przywrócenie danych w wymaganym formacie. Przepływ danych na diagramie DFD jest reprezentowany przez linię ze strzałką na jednym końcu, przy czym strzałka wskazuje kierunek przepływu danych. Każdy strumień danych ma swoją własną nazwę, odzwierciedlającą jego zawartość.

W ten sposób model informacyjny systemu w notacji DFD budowany jest w postaci diagramów przepływu danych, które są przedstawiane graficznie za pomocą odpowiedniej notacji. Jako przykład rozważmy uproszczony model procesu przyjmowania określonej kwoty gotówki na kartę kredytową przez klienta banku. Podmioty zewnętrzne w tym przykładzie to klient banku i ewentualnie pracownik banku kontrolujący proces obsługi klienta. Akumulator danych może stanowić bazę danych o stanie rachunków poszczególnych klientów banku. Poszczególne strumienie danych odzwierciedlają naturę przesyłane informacje wymagane do obsługi klienta banku. Odpowiedni model dla tego przykładu można przedstawić w postaci diagramu przepływu danych (rysunek 2.19).

Obecnie diagramy przepływu danych są wykorzystywane w niektórych narzędziach CASE do budowy modeli informacyjnych systemów przetwarzania danych. Główną wadą tej metodologii jest również brak wyraźnych środków do obiektowej reprezentacji złożonych modeli systemów, a także do reprezentacji złożonych algorytmów przetwarzania.

dane. Ponieważ charakterystyki czasu wykonania poszczególnych procesów i transferu danych pomiędzy procesami nie są wskazane na diagramach DFD, modele systemów realizujących synchroniczne przetwarzanie danych nie mogą być odpowiednio reprezentowane w notacji DFD. Wszystkie te cechy metodyki analizy systemów konstrukcyjnych ograniczyły możliwości jej szerokiego zastosowania i posłużyły jako podstawa do włączenia odpowiednich narzędzi do ujednoliconego języka modelowania.

Ryż. 2.19. Przykładowy diagram DFD dla procesu pobierania gotówki z karty kredytowej

Przy budowaniu modelu funkcjonalnego systemu alternatywą dla metodologii () jest metodologia diagramy przepływu danych (Diagramy przepływu danych, DFD). W przeciwieństwie do , przeznaczonego do projektowania systemów w ogóle, DFD jest przeznaczone do projektowania systemów informatycznych. Koncentracja tej metodologii na projektowaniu systemy zautomatyzowane sprawia, że ​​jest to wygodne i bardziej opłacalne narzędzie do budowania funkcjonalnego modelu TO-BE.

Przy konstruowaniu diagramów rozróżnia się elementy notacji graficznej przedstawione w tabeli. 6.1.

Tabela 6.1. Elementy zapisu graficznego DFD

Nazwa	Notacja jordańska	Notacja Gein-Sarson
Strumień danych
Proces (system, podsystem)
Przechowywanie danych
podmiot zewnętrzny

Strumień danych definiuje informację (obiekt materialny) przekazywaną jakimś połączeniem od źródła do odbiorcy. Rzeczywistym przepływem danych mogą być informacje przesyłane kablem między dwoma urządzeniami, wysyłane pocztą, listami, taśmami magnetycznymi lub dyskietkami, przesyłane z jednego komputera na drugi itp.

Każdy strumień danych ma nazwę, która odzwierciedla jego zawartość. Kierunek strzałki wskazuje kierunek przepływu danych. Czasami informacje mogą poruszać się w jednym kierunku, zostać przetworzone i zwrócone z powrotem do źródła. Taka sytuacja może być modelowana albo przez dwa różne przepływy, albo przez jeden - dwukierunkowy.

Definicja jakiegoś obiektu, podmiotu lub systemu jako bytu zewnętrznego wskazuje, że znajduje się on poza granicami projektowanego System informacyjny. W rezultacie encje zewnętrzne są zwykle wyświetlane tylko na diagramie kontekstowym DFD. W procesie analizy i projektowania niektóre podmioty zewnętrzne można w razie potrzeby przenieść na diagramy dekompozycji lub odwrotnie, część procesów (podsystemów) można przedstawić jako podmiot zewnętrzny.

Budowa funkcjonalnego modelu DFD rozpoczyna się, podobnie jak w IDEF0, od opracowania diagramu kontekstowego. Wyświetla proces główny (sam system jako całość) i jego powiązania z otoczeniem zewnętrznym (byty zewnętrzne). Ta interakcja jest pokazana za pomocą strumieni danych. Dozwolone jest jednoczesne wyświetlanie kilku głównych procesów lub podsystemów na diagramie kontekstowym. Przykładowy diagram kontekstowy dla rozważanego problemu pokazano na poniższym rysunku.

Ryż. 6.23. Schemat kontekstowy systemu wyznaczania dopuszczalnych prędkości (metodologia DFD)

Z diagramu tego wynika, że ​​jako źródło danych początkowych dla działania systemu można wykorzystać bazę danych ARM-P (Stacja robocza obsługi toru) lub SBD-P (Consolidated DB - Way Fragment), która zawiera prawie wszystkie niezbędne informacje na odcinkach dróg.

Jednocześnie system zachowuje możliwość jego ręcznego wprowadzania i regulacji. Pomimo tego, że bazy danych ARM-P czy SDB-P są podmiotami zewnętrznymi w stosunku do systemu, są one pokazywane jako magazyn danych dla lepszej percepcji.

Kolejnym procesem projektowym jest budowanie diagramów dekompozycji, które są budowane (pokaż urządzenie) tylko dla procesów lub podsystemów (systemów) .

Schemat rozkładu pierwszego poziomu projektowanego układu przedstawia poniższy rysunek.

Ryż. 6.24. Diagram rozkładu pierwszego poziomu (metodologia DFD)

Na tym rysunku niektóre strumienie danych związane z dyskami nie mają nazw. Pozwala to wyeliminować powielanie etykiet, a w rezultacie zmniejszyć nasycenie diagramu.

Podczas konstruowania diagramu dekompozycji bloki systemu w niektórych przypadkach są wyświetlane jako procesy (nazwa zaczyna się od czasownika), w innych - jako podsystemy (nazwa zaczyna się od słowa „podsystem”). Ma to na celu zilustrowanie zasad nazewnictwa bloków. Jednocześnie dekompozycja systemu może być reprezentowana albo za pomocą samych procesów, albo tylko podsystemów.

Diagram kontekstowy i diagram dekompozycji są tworzone przy użyciu BPwin 4.0.

Decyzję o uzupełnieniu szczegółów procesu i zastosowaniu mini-specyfikacji podejmuje projektant na podstawie następujących kryteriów:

Proces ma stosunkowo niewielką liczbę strumieni danych wejściowych i wyjściowych (2–3 strumienie);

Umiejętność opisu procesów w postaci prostego algorytmu;

Możliwości opisania logiki procesu za pomocą mini-specyfikacji małej objętości (nie więcej niż 20-30 wierszy).

Model DFD oprócz opisu funkcjonalnego aspektu systemu zawiera również informacje o aspektach informacyjnych i komponentowych. Zestaw urządzeń do przechowywania danych jest prototypem przyszłej bazy danych, tj. określa skład i strukturę informacji. Konstrukcja diagramów z wykorzystaniem podsystemów jako bloków pokazuje skład i połączenia elementów przyszłego systemu.

6.12. Rozszerzenia DFD dla systemów czasu rzeczywistego

Systemy czasu rzeczywistego są z reguły budowane na interakcji środków Informatyka oraz różne urządzenia fizyczne do pobierania informacji (czujniki, kamery, mikrofony itp.). Te pierwsze to dyskretne przetworniki informacji, te drugie to głównie przetworniki analogowe, tj. generowanie informacji w ciągłym strumieniu. Inną cechą takich systemów jest znaczne nastawienie na zarządzanie obiektami. Aby modelować zachowanie systemów czasu rzeczywistego, P. Ward i S. Mellor zasugerowali użycie dodatkowych elementów na DFD.

DFD ), która zapewnia poprawny opis wyjść (odpowiedź systemu w postaci danych) dla danego wpływu na wejście systemu (sygnały poprzez interfejsy zewnętrzne). Diagramy przepływu danych są głównym środkiem modelowania wymagania funkcjonalne do projektowanego systemu.

Podczas tworzenia diagramy przepływu danych Stosowane są cztery podstawowe pojęcia: strumienie danych, procesy (prace) przekształcania strumieni danych wejściowych na wyjściowe, podmioty zewnętrzne, przechowywanie (magazynowanie) danych.

Strumienie danych to abstrakcje używane do modelowania transferu informacji (lub komponentów fizycznych) z jednej części systemu do drugiej. Przepływy na diagramach są reprezentowane przez nazwane strzałki, których orientacja wskazuje kierunek przepływu informacji.

Zamiar proces(pracy) polega na wytwarzaniu strumieni wyjściowych ze strumieni wejściowych zgodnie z akcją podaną przez nazwę procesu. Nazwa procesu musi zawierać nieokreślony czasownik, po którym następuje dodatek (na przykład „odbierz dokumenty wysyłkowe”). Każdy proces ma unikalny numer, do którego można się odnieść na diagramie, który można wykorzystać w połączeniu z numerem diagramu, aby uzyskać unikalny indeks proces w całym modelu.

Przechowywanie danych (dysk) umożliwia zdefiniowanie danych w określonych obszarach, które będą przechowywane w pamięci pomiędzy procesami. W rzeczywistości pamięć masowa reprezentuje „kawałki” strumieni danych w czasie. Zawarte w nim informacje można wykorzystać w dowolnym momencie po ich otrzymaniu, a dane można wybierać w dowolnej kolejności. Nazwa repozytorium musi identyfikować jego zawartość i być rzeczownikiem.

podmiot zewnętrzny reprezentuje materialny obiekt poza kontekstem systemu, który jest źródłem lub odbiorcą danych systemowych. Jego nazwa musi zawierać rzeczownik, np. „magazyn towarów”. Zakłada się, że obiekty reprezentowane jako podmioty zewnętrzne, nie powinien uczestniczyć w żadnym przetwarzaniu.

Oprócz głównych elementów DFD zawiera słowniki danych i mini-specyfikacje.

Słowniki danych to katalogi wszystkich elementów danych obecnych w DFD , w tym grupowe i indywidualne strumienie danych, magazyny i procesy oraz wszystkie ich atrybuty.

Przetwarzanie minispecyfikacji- opisać procesy DFD niższego poziomu. W rzeczywistości mini-specyfikacje są algorytmami opisu zadań wykonywanych przez procesy: zbiór wszystkich mini-specyfikacji jest kompletną specyfikacją systemu.

Proces budowania DFD rozpoczyna się od stworzenia tzw. diagramu głównego typu „gwiazda”, który przedstawia symulowany proces i wszystkie podmioty zewnętrzne z którymi współdziała. W przypadku złożonego procesu głównego jest on natychmiast przedstawiany jako rozkład na szereg oddziałujących ze sobą procesów. Kryteria złożoności w tym przypadku to: obecność dużej liczby podmioty zewnętrzne, wielofunkcyjność systemu, jego rozproszony charakter. Podmioty zewnętrzne są alokowane w odniesieniu do procesu głównego. Do ich ustalenia niezbędna jest identyfikacja dostawców i konsumentów procesu głównego, tj. wszystkie obiekty, które wchodzą w interakcję z głównym procesem. Na tym etapie opis interakcji polega na wyborze czasownika, który daje wyobrażenie o tym, w jaki sposób podmiot zewnętrzny używa lub jest wykorzystywany przez proces główny. Na przykład głównym procesem jest „rozliczanie odwołań obywateli”, podmiot zewnętrzny to „obywatele”, opis interakcji to „składa wnioski i otrzymuje odpowiedzi”. Ten etap jest fundamentalnie ważny, ponieważ określa granice modelowanego systemu.

Dla wszystkich podmioty zewnętrzne budowana jest tabela zdarzeń opisująca ich interakcję z głównym wątkiem. Tabela zdarzeń zawiera nazwę podmiotu zewnętrznego, zdarzenie, jego typ (typowy dla systemu lub wyjątkowy, realizowany w określonych warunkach) oraz odpowiedź systemu.

Następnym krokiem jest dekompozycja głównego procesu na zestaw powiązanych ze sobą procesów, które wymieniają strumienie danych. Same przepływy nie są określone, określany jest jedynie charakter interakcji. Rozkład kończy się, gdy proces staje się prosty, tj.:

1. proces ma dwa lub trzy strumienie wejściowe i wyjściowe;
2. proces można opisać jako przekształcenie danych wejściowych w dane wyjściowe;
3. proces można opisać jako algorytm sekwencyjny.

Dla prostych procesów budowana jest mini-specyfikacja - formalny opis algorytmu konwersji danych wejściowych na dane wyjściowe.

Minispecyfikacja spełnia następujące wymagania: dla każdego procesu tworzona jest jedna specyfikacja; specyfikacja jednoznacznie definiuje strumienie wejściowe i wyjściowe dla danego procesu; specyfikacja nie definiuje, w jaki sposób strumienie wejściowe są konwertowane na strumienie wyjściowe; specyfikacja odnosi się do istniejących elementów bez wprowadzania nowych; specyfikacja wykorzystuje standardowe podejścia i operacje, gdy tylko jest to możliwe.

Po rozłożeniu głównego procesu dla każdego podprocesu budowana jest podobna tabela wydarzenia wewnętrzne.

Kolejnym krokiem po zdefiniowaniu pełnej tabeli zdarzeń jest podświetlenie strumienie danych między procesami i podmioty zewnętrzne. Najprostszym sposobem ich wyizolowania jest analiza tabel zdarzeń. Zdarzenia są konwertowane na strumienie danych od inicjatora zdarzenia do żądanego procesu, a reakcje są konwertowane na odwrotny strumień zdarzeń. Po zbudowaniu strumieni wejściowych i wyjściowych w podobny sposób konstruowane są strumienie wewnętrzne. W celu ich przypisania do każdego z procesów wewnętrznych przydzielani są dostawcy i konsumenci informacji. Jeśli dostawca informacji lub konsument reprezentuje proces przechowywania lub żądania informacji, wówczas wprowadzany jest magazyn danych, dla którego ten proces jest interfejsem.

Po zbudowaniu przepływów danych diagram należy sprawdzić pod kątem kompletności i spójności. Kompletność diagramu jest zapewniona, jeśli w systemie nie ma „zawieszonych” procesów, które nie są wykorzystywane w procesie przetwarzania strumieni wejściowych na strumienie wyjściowe. Spójność systemu zapewnia implementacja zestawów reguł formalnych dotyczących możliwych typów procesów: nie może być przepływu na diagramie łączącym dwa podmioty zewnętrzne– ta interakcja jest usuwana z rozważania; żaden podmiot nie może bezpośrednio odbierać ani udzielać informacji do magazynu danych – magazyn danych jest elementem pasywnym zarządzanym przez proces interfejsu; dwa magazyny danych nie mogą bezpośrednio wymieniać informacji - te magazyny muszą być połączone.

Zalety techniki DFD nie różnią się od konwencjonalnych; brak pojęcia czasu, tj. brak analizy przedziałów czasowych przy konwersji danych (wszystkie terminy muszą być wpisane w specyfikacjach procesów).

Zastanów się nad zbudowaniem modelu DFD systemu informatycznego dla sieci sklepów sprzedających torby. Uzupełnijmy zbudowany w pracy laboratoryjnej nr 1 diagram IDEF0 o diagram DFD. Zbudujmy diagram DFD dla funkcji A4 "Analizuj pracę" Zobacz rys. cztery.

Ryż. 4. Przykład diagramu DFD

Ćwiczenie

1. Poznaj metodę DFD.
2. Suplement model funkcjonalny system informacyjny, zbudowany w pracy laboratoryjnej nr 1, schemat przepływu danych, dla tych bloków funkcjonalnych modelu IDEF0, dla których chcesz pokazać ruch danych.
3. Odpowiedz na pytania bezpieczeństwa.
4. Sporządzić sprawozdanie ( Strona tytułowa, zadanie, diagram DFD)

pytania testowe

1. Jakie procesy w systemie są opisane za pomocą diagramów przepływu danych?
2. Jakie są główne obiekty diagramów przepływu danych?
3. Czy przy konstruowaniu diagramów DFD stosuje się zasadę dekompozycji?
4. Miejsce, w którym strzałka wpada w klocek lub w którym strzałka opuszcza klocek może być dowolne lub podlegać pewnym zasadom?
5. W jaki sposób obiekt jest przydzielany podmiotowi zewnętrznemu?

Literatura

1. Fedotova, DE Technologie CASE: Practicum / D.E. Fedotova, Yu.D. Semenov, K.N. Czyżyk. - M.: Infolinia- Telekomunikacja, 2005 r. - 160 s.: chor.
2. Kalashyan, A.N. Modele konstrukcyjne biznes: technologie DFD / A.N. Kalashyan, G.N. Kaljanow. - M.: Finanse i statystyka, 2003.
3. Diagramy przepływu danych DFD. - http://www.proinfotech.ru/dmdlr2.htm.
4. Metody modelowania procesów biznesowych. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Budowanie diagramu dekompozycji w notacji DFD

Cel:

• zbuduj diagram dekompozycji w notacji DFD z jednego z diagramów IDEF0, które zostały zbudowane w poprzednich laboratoriach

Diagramy przepływu danych (Dataflowdiagram, DFD) służą do opisu przepływu pracy i przetwarzania informacji. Podobnie jak IDEF0, DFD reprezentuje modelowany system jako sieć powiązanych działań. Mogą być używane jako dodatek do modelu IDEF0 w celu bardziej wizualnego wyświetlania bieżących operacji przepływu pracy w korporacyjnych systemach przetwarzania informacji. Głównym celem DFD jest pokazanie, w jaki sposób każde zadanie przekształca swoje dane wejściowe w wyniki oraz ujawnienie relacji między tymi zadaniami.

Dowolny diagram DFD może zawierać zadania, jednostki zewnętrzne, strzałki (przepływy danych) i magazyny danych.

Pracuje. Prace reprezentowane są przez prostokąty z zaokrąglonymi rogami (rys. 1), ich znaczenie pokrywa się ze znaczeniem prac IDEF0 i IDEF3. Podobnie jak działa IDEF3, mają wejścia i wyjścia, ale nie obsługują kontrolek i mechanizmów takich jak IDEF0. Wszystkie aspekty pracy są sobie równe. Każde zadanie może mieć wiele strzałek wchodzących i wychodzących.

Rysunek 1. Praca w DFD

podmioty zewnętrzne. Podmioty zewnętrzne reprezentują wejścia i/lub wyjścia z systemu. Jeden podmiot zewnętrzny może jednocześnie dostarczać wejścia (działając jako dostawca) i odbierać wyjścia (działając jako odbiorca). Podmiot zewnętrzny to obiekt materialny, taki jak klienci, personel, dostawcy, klienci, magazyn. Zdefiniowanie jakiegoś obiektu lub systemu jako podmiotu zewnętrznego wskazuje, że znajduje się on poza granicami analizowanego systemu. Podmioty zewnętrzne są przedstawione jako prostokąt z cieniem i zwykle znajdują się na krawędziach diagramu (ryc. 2).

Rysunek 2. Podmiot zewnętrzny w DFD

Strzałki (strumienie danych). Strzałki opisują ruch obiektów z jednej części systemu do drugiej (stąd wynika, że ​​diagram DFD nie może mieć strzałek granicznych). Ponieważ wszystkie boki pracy w DFD są równe, strzałki mogą zaczynać się i kończyć po dowolnej stronie prostokąta. Strzałki mogą być dwukierunkowe.

Magazyn danych. W przeciwieństwie do strzałek opisujących obiekty w ruchu, hurtownie danych przedstawiają obiekty w spoczynku (Rysunek 3). Magazyn danych to abstrakcyjne urządzenie do przechowywania informacji, które można umieścić na dysku w dowolnym momencie i pobrać po pewnym czasie, a sposoby umieszczania i pobierania mogą być dowolne. W ogólnym przypadku jest to prototyp przyszłej bazy danych, a opis przechowywanych w niej danych musi odpowiadać modelowi informacyjnemu (Entity-RelationshipDiagram).

Rysunek 3. Przechowywanie danych w DFD

Rozkładanie pracy IDEF0 na diagram DFD. Podczas rozkładania pracy IDEF0 na DFD musisz wykonać następujące czynności:

• usuń wszystkie strzałki graniczne na diagramie DFD;
• tworzyć odpowiednie podmioty zewnętrzne i magazyny danych;
• tworzyć strzałki wewnętrzne, zaczynając od jednostek zewnętrznych zamiast strzałek granicznych;
• strzałki na tunelu diagramu IDEF0

Ścisłe przestrzeganie zasad notacji DFD nie zawsze jest wygodne, więc BPWin umożliwia tworzenie strzałek granicznych na diagramach DFD.

Budowanie diagramu dekompozycji. Rozłóżmy pracę Wysyłka i dostawa schemat A0 „Działalność przedsiębiorstwa w zakresie montażu i sprzedaży komputerów i laptopów”. W tej pracy zidentyfikowaliśmy następujące prace podrzędne:

• pozyskiwanie niezbędnych komponentów - zajmuje się czynnościami związanymi ze znalezieniem odpowiednich dostawców i zamawianiem u nich niezbędnych komponentów
• przechowywanie podzespołów i zmontowanych komputerów,
• wysyłka gotowych produktów - wszystkie czynności związane z pakowaniem, formalnościami i faktyczną wysyłką gotowych produktów

Przydzielmy pracę Wysyłka i dostawa diagram A0 „Działalność przedsiębiorstwa w zakresie montażu i sprzedaży komputerów i laptopów”, kliknij przycisk „GotoChildDiagram” na pasku narzędzi i wybierz notację DFD. Tworząc diagram potomny, BPWin przekazuje strzałki graniczne pracy nadrzędnej, należy je usunąć i zastąpić zewnętrznymi encjami. Strzałki mechanizmu, strzałki kontrolne „Zasady i procedury”, „ Informacje kontrolne" i strzałka wyjścia "Raporty" na diagramie podrzędnym nie będą używane, aby nie zaśmiecać diagramu mniej istotnymi szczegółami. Reszta strzałek zostanie zastąpiona przez zewnętrzne podmioty - przycisk "ExternalReferenceTool" na pasku narzędzi, w wyświetlonym oknie wybierz przycisk opcji „Strzałka” i wybierz żądaną z nazwy listy (rys. 4):

Rysunek 4. Dodawanie podmiotu zewnętrznego

Rysunek 5. Miejsca pracy i podmioty zewnętrzne

Centralnym punktem jest tutaj praca „Przechowywanie komponentów i zmontowanych komputerów”. Otrzymuje zmontowane komputery i komponenty otrzymane od dostawców, a także listę komponentów niezbędnych do montażu komputerów. Wynikiem tej pracy będą niezbędne komponenty (jeśli występują), lista brakujących komponentów, przekazana na wejście pracy „Dostarcz niezbędne komponenty” oraz zmontowane komputery przekazane do wysyłki. Wynikiem pracy „Dostarczenie niezbędnych komponentów” i „Wysyłka wyrobów gotowych” będą odpowiednio zamówienia do dostawców i wyroby gotowe.

Następnym krokiem jest ustalenie, jakie informacje są potrzebne do każdej pracy, tj. należy umieścić na schemacie hurtowni danych (rys. 6).

Rysunek 6. Ostateczny diagram rozkładu

Zadanie „Zakup niezbędnych części” dotyczy informacji o dostawcach oraz informacji o zamówieniach złożonych u tych dostawców. Strzałka łącząca zadanie i magazyn danych „Lista dostawców” jest dwukierunkowa. zadanie może zarówno otrzymywać informacje o istniejących dostawcach, jak i wprowadzać dane o nowych dostawcach. Strzałka łącząca zlecenie z hurtownią danych „Lista zleceń” jest jednokierunkowa, ponieważ praca wprowadza tylko informacje o złożonych zamówieniach.

Zadanie "Przechowywanie podzespołów i zmontowanych komputerów" działa z informacjami o otrzymanych i wydanych podzespołach oraz zmontowanych komputerach, dlatego strzałki łączące pracę z magazynami danych "Lista podzespołów" i "Lista zmontowanych komputerów" są dwukierunkowe. Również ta praca, po otrzymaniu komponentów, powinna odnotować, że zamówienie do dostawców zostało zrealizowane. W tym celu jest on połączony z magazynem danych „Lista zamówień” za pomocą strzałki jednokierunkowej. Należy pamiętać, że ta sama pamięć danych może zostać zduplikowana na diagramach DFD.

Wreszcie zadanie „Wysyłka gotowych produktów” powinno przechowywać informacje o zrealizowanych wysyłkach. W tym celu należy wprowadzić odpowiedni magazyn danych – „Dane do wysyłki”.

Ostatnim krokiem jest tunelowanie strzałek pracy nadrzędnej (ryc. 7):

Rysunek 7. Diagram IDEF0 z tunelowanymi strzałkami dla zadania Wysyłka i dostawa

• krótki opis dzieła do rozłożenia
• diagram rozkładu

Przykładowy diagram DFD procesu „Opracowanie zadania technologicznego” przy użyciu Bpwin