Budowanie diagramów przepływu danych dfd. Metodologie modelowania domen. Materiał z PIE.Wiki

(Wykład 5)

Metody projektowania baz danych

Celem projektowania bazy danych jest odpowiednie przedstawienie w bazie danych istoty obszaru tematycznego rozpatrywanego z punktu widzenia rozwiązania problemu automatyzacji.

W teorii baz danych istnieje wiele metod tworzenia modeli baz danych, które odzwierciedlają różne poziomy jej architektury. Istnieją dwa powszechne podejścia do projektowania systemów baz danych: od góry do dołu i od dołu do góry.

Znane jest również podejście „strategii mieszanej” – najpierw dla różnych części modelu stosuje się metody „od dołu do góry” i „od góry do dołu”, po czym wszystkie przygotowane fragmenty składa się w jedną całość.

Spójrzmy na rysunek, aby zobaczyć różnicę między tymi metodami.

Rysunek - Wybór metody projektowania

Metoda projektowania bazy danych od dołu do góry

W podejściu oddolnym projektowanie konstrukcyjne odbywa się od dołu do góry. Proces ten nazywany jest procesem syntezy, próbą uzyskania całości, która adekwatnie odzwierciedla opis przedmiotu, w oparciu o opis jego części składowych.

Etapy projektowania bazy danych metodą projektowania oddolnego przedstawiono na rysunku 2.

DLM - model danych logiczny; NF - postać normalna; ILM – informacyjno-logiczny model obszaru tematycznego; MDB - model bazy danych.

Rysunek 2 – Etapy projektowania bazy danych metodą projektowania oddolnego

Praca nad relacyjną bazą danych rozpoczyna się od zdefiniowania właściwości obiektów (atrybutów encji) obszaru tematycznego, które na podstawie analizy istniejących między nimi relacji grupuje się w relacje relacyjne (tabele) wyświetlające te obiekty (w przypadku że projektujemy strukturę relacyjnej bazy danych).

Z reguły otrzymujesz 2–3 powiązane ze sobą relacje relacyjne.

Redundancja danych w schemacie nieznormalizowanym - powtarzalność danych w bazie danych.

Aby mieć pewność, że wynikowa struktura bazy danych (DLM) nie będzie miała różnych anomalii podczas dodawania, aktualizacji lub usuwania danych ze względu na ich redundancję, konieczne jest sprawdzenie każdego wynikowego schematu relacji przynajmniej pod kątem zgodności z 3NF. Jeśli wzorce relacji nie spełniają tego warunku, a zwykle tak się nie dzieje, należy przeprowadzić proces normalizacji.

Znaczna ilość działań mających na celu normalizację schematów relacji relacyjnych nadała wręcz drugie imię metodzie projektowania „oddolnego”. Metodę tę często nazywa się metodą „normalizacyjną”.

Podstawy teorii normalizacji stworzył E. Codd.

Normalizacja to proces projektowania pod względem RMD metodą kolejnych przybliżeń do zadowalającego zestawu obwodów.

Zbiór schematów relacji nazywany jest schematem relacyjnej bazy danych.

Normalizacja eliminuje nadmiarowość i anomalie w bazie danych.

Anomalie na nieznormalizowanym diagramie relacji:

a) aktualizacje – niespójność danych spowodowana ich redundancją i częściową aktualizacją.

Przykład: Schemat 2

(Kod nauczyciela, Imię i nazwisko nauczyciela, Kod działu, Nazwa działu, Krótkie imię dział, kod stanowiska, tytuł stanowiska)

b) anomalia usunięcia – niezamierzona utrata danych spowodowana usunięciem innych danych

c) anomalia wejściowa – brak możliwości wprowadzenia danych do tabeli spowodowany brakiem innych danych.

Schemat 2 (Kod nauczyciela, Imię i nazwisko nauczyciela, Kod działu, Nazwa działu, Skrócona nazwa działu, Kod stanowiska, Nazwa stanowiska)

Etapy projektowania bazy danych metodą normalizacyjną:

1. Określenie wszystkich atrybutów, o których informacja będzie zawarta w bazie danych – gromadzenie danych surowych w przedsiębiorstwie.

2. Sporządzanie zestawienia danych surowych w postaci diagramów relacji relacyjnych. Powstały diagram relacji ma zerową postać normalną (0NF).

3. Zmniejszenie schematu relacji do 1NF

def. 1NF: Schemat relacji znajduje się w 1NF wtedy i tylko wtedy, gdy wszystkie atrybuty schematu mają wartość atomową, a w schemacie relacji nie ma powtarzających się grup.

Definicja: Grupa powtarzalna to jeden lub więcej elementów danych, które mają więcej niż jedną wartość dla pojedynczej części klucza. Rozważane, jeśli klucz podstawowy jest złożony.

Rozbicie schematu relacji na atrybuty atomowe.

Usuwanie zduplikowanych grup.

PG: ZAMÓWIENIE (nr Klienta, F., I., O., tel., data, nr zamówienia)

Klucz podstawowy - numer klienta, data, numer zamówienia (jeśli klient może złożyć więcej niż jedno zamówienie tego samego dnia)

Grupa powtarzalna: F, I, O, telefon - powtarzane w każdym nowy wpis przy generowaniu informacji o nowym zamówieniu, choć informacja ta dotyczy części klucza złożonego – Numeru Klienta.

Konieczne jest umieszczenie osobnego diagramu relacji:

ZAMÓWIENIE (numer klienta, data, numer zamówienia)

OSOBY INDYWIDUALNE (numer klienta, imię i nazwisko, imię i nazwisko, adres, numer telefonu)

Relacja 1:M pomiędzy 2 nowymi schematami relacji, „wiele” po stronie ZAMÓWIENIA relacji.

Każda OSOBA INDYWIDUALNA może złożyć wiele ZAMÓWIEŃ.

Każde konkretne ZAMÓWIENIE składane jest przez jedną i tylko jedną OSOBĘ.

4. Badanie znaczenia (semantyki) danych i określenie zbioru atrybutów – potencjalnego (unikalnego) klucza relacji. M.b. kilka unikalnych kluczy.

Unikalny (potencjalny) klucz to atrybut lub zestaw atrybutów, który całkowicie i jednoznacznie definiuje wartości innych atrybutów.

5. Jeżeli relacja ma kilka potencjalnych kluczy, to spośród nich należy wybrać kandydata na klucz podstawowy.

6. Identyfikacja zależności funkcjonalnych pomiędzy atrybutami schematu relacji znormalizowanej.

Definicja: zależność funkcjonalna atrybutu B (zbioru atrybutów) relacji R od atrybutu (zbioru atrybutów) A relacji R, oznaczanej R.A -> R.B A->B

takie połączenie pomiędzy atrybutami relacji nazywa się tak, że w każdym momencie każdej wartości atrybutu (zestawu atrybutów) B odpowiada tylko jedna wartość atrybutu (zestawu atrybutów) A.

Jednakże dla danej wartości atrybutu B może być ich kilka różne znaczenia atrybut A.

Jeśli zatem znamy wartość atrybutu A z semantyki obszaru tematycznego, to w obszarze przedmiotowym możemy jednoznacznie określić wartość atrybutu B.

FZ jest właściwością semantyczną atrybutów relacji.

W związku z m.b. Zidentyfikowano wiele zależności funkcjonalnych, m.in. w stosunku do m.b. zidentyfikowano wiele determinantów.

Def: atrybut kluczowy - atrybut będący częścią klucza podstawowego Def: atrybut niekluczowy - atrybut niebędący częścią klucza podstawowego.

Definicja: częściowy FL to zależność atrybutu niebędącego kluczem od części złożonego klucza podstawowego.

Def: pełny FL to zależność atrybutu innego niż klucz od całego złożonego klucza podstawowego.

W przypadku komputera złożonego sensowne jest rozważenie pełnego i częściowego FL.

Praca (numer szkoły (VK1); numer instruktora (PC); nazwisko instruktora; imię instruktora; patronimika instruktora; seria paszportu; numer paszportu; data zatrudnienia; numer rejestracyjny pojazdu; kod rodzaju zawodu (VK3))

Zależności funkcjonalne:

Numer instruktora -> Numer szkoły Numer instruktora -> Nazwisko instruktora Numer instruktora -> Imię i nazwisko instruktora

Numer instruktora -> Patronimika instruktora Numer instruktora - > Seria paszportu Numer instruktora -> Numer paszportu Numer instruktora - > Kod wykształcenia Numer instruktora - > Data zatrudnienia Numer instruktora - > Numer rejestracyjny pojazdu

Jest funkcjonalnie kompletny począwszy od klucza podstawowego Numer Instruktora, kod typu klasy nie jest zależny od żadnego atrybutu niebędącego kluczem.

Aby przeprowadzić konwersję do 2NF, konieczne jest zidentyfikowanie podzbioru FZ atrybutów niekluczowych ze złożonego klucza podstawowego. Ile niekluczowych atrybutów - tyle przepisów federalnych!

Uwaga: pełny zbiór FZ wyznaczany jest na podstawie aksjomatów i twierdzeń teorii mnogości.

7. Schemat redukcji relacji do 2NF Technologia redukcji do 2NF:

1) Złożony klucz podstawowy i te atrybuty, które są od niego w pełni funkcjonalnie zależne, umieszczono w osobnym diagramie relacji. Jeśli nie ma takich atrybutów, istnieje tylko jeden klucz podstawowy.

2) Część klucza podstawowego i te atrybuty, które są w pełni funkcjonalnie zależne od tej części, są umieszczone w osobnym schemacie.

Ile części klucza podstawowego utworzyło częściowe FZ, tyle schematów otrzymujemy

3) Oryginalny diagram został usunięty.

8. Wyznaczanie zależności przechodnich w każdej relacji normalizowalnej

Definicja: zależność przechodnia - atrybut C relacji R zależy przechodnio od atrybutu A relacji R, jeżeli dla atrybutów A, B, C spełniony jest warunek istnienia następujących ustaw federalnych:

pod warunkiem, że atrybut A jest funkcjonalnie niezależny od atrybutu B lub atrybutu C.

9. Usuwanie zależności przechodnich poprzez dekompozycję diagramów relacji

10 Określenie przesłanek konieczności analizy schematów relacji pod kątem zgodności z BCNF (forma normalna Boyce’a-Codda – BCNF)

Ta postać normalna wprowadza dodatkowe ograniczenie w porównaniu do

Def: Relacja jest w BCNF jeśli jest w 3NF i każdy wyznacznik relacji jest potencjalnym kluczem relacji.

Definitywnie: Wyznacznikiem prawa federalnego jest atrybut (zestaw atrybutów),

znajduje się po lewej stronie ustawy federalnej, tj. niektóre inne atrybuty funkcjonalnie całkowicie zależą od wyznacznika

W związku z m.b. kilka wyznaczników

Sytuacja, w której relacja będzie w 3NF, a nie w BCNF, ma miejsce pod warunkiem, że relacja ma dwa (lub więcej) możliwe (potencjalne) klucze, które są złożone i mają wspólny atrybut.

Zatem BCNF bierze pod uwagę FZ, które obejmują wszystkie potencjalne klucze relacji, a nie tylko komputery PC.

W praktyce taka sytuacja jest dość rzadka i dla wszystkich pozostałych relacji 3NF i BCNF są równoważne.

W przypadku relacji z pojedynczym kluczem kandydującym jej 3NF jest równoważne BCNF.

Zatem dla pomyślnej normalizacji (do 3NF) konieczna jest analiza obszaru tematycznego (analiza dokumentów

obszar tematyczny) dla każdego schematu relacji relacyjnych:

Zidentyfikuj potencjalne wskazówki;

Zobacz powtarzające się grupy i atrybuty nieatomowe;

Wprowadź schematy relacji do 1NF;

Zdefiniuj zależności funkcjonalne pomiędzy atrybutami niekluczowymi a kluczem podstawowym;

Identyfikacja częściowych zależności funkcjonalnych;

Przeprowadzić dekompozycję (podział) odpowiednich diagramów zależności w celu usunięcia częściowych zależności funkcjonalnych;

Zobacz zależności przechodnie między atrybutami niekluczowymi a kluczem podstawowym;

Wyeliminuj zależności przechodnie poprzez dekompozycję

odpowiednie schematy relacji.

Wykonywanie tych czynności jest procesem dość pracochłonnym. Na przykład identyfikacja pełnego zestawu zależności funkcjonalnych będzie wymagała znajomości teorii mnogości i logiki predykatów.

Aby doprowadzić schematy relacji do wyższych form normalnych, konieczne jest przeprowadzenie dodatkowych badań przedmiotu w celu określenia determinant relacji, identyfikacji wielowartościowych zależności pomiędzy atrybutami relacji oraz zależności powiązań.

Rozważmy na rysunku schemat procesu normalizacji

Rysunek - Schemat procesu normalizacji

Projektowanie oddolne jest dość złożoną i przestarzałą techniką, która nadaje się tylko do projektowania małych baz danych.

Obszar tematyczny - automatyzacja rejestracji danych osobowych instruktorów sieci szkół nauki jazdy.

Wzrosła liczba studentów, wzrosła także liczba instruktorów i pojawiła się potrzeba automatyzacji.

Na etapie komunikacji z Klientem zidentyfikowano następujące atrybuty, które wymagają przechowywania i przetwarzania:

Numer szkoły;

Imię i nazwisko instruktora;

Data urodzenia;

Numer, seria paszportu;

Data zatrudnienia;

Numer rejestracyjny samochodu przypisany instruktorowi (należy zachować

ostatni wpis to życzenie klienta, choć historię trzeba zachować w sposób polubowny);

Należy także zapisać wyłącznie rodzaj zajęć, jakie pracownik prowadzi (wykład, jazda samochodem). najnowsze informacje- zdjęcie chwili, nie potrzeba żadnej historii.

Zidentyfikowane ograniczenia obszaru tematycznego:

Wszystkie dane muszą być obowiązkowe.

Może na jeden samochód. Przydzielonych jest kilku instruktorów.

Numer pracownika jest unikalny w obrębie całego IS obejmującego sieć szkół.

Wypełnienie wierszy rzeczywistymi danymi pozwoliło nam zidentyfikować kandydata na klucz podstawowy. Seria i numer dokumentu tożsamości składa się z dwóch atrybutów; można go zastąpić wpisując dodatkowy numer - numer osobisty instruktora. Wyszło to również na jaw podczas dalszej analizy tematu – pracownik prowadzący akta osobowe instruktorów przydziela każdemu z nich osobisty numer.

Pole „rodzaj zawodu” ma charakter symboliczny, co jest niepożądane w przypadku atrybutu będącego częścią klucza podstawowego. W trakcie dalszej analizy tematyki odnaleziono dokument, który ją wymienił istniejące gatunki klasy szkoły nauki jazdy, a wpisy zostały ponumerowane w nagłówku dokumentu sprawozdawczego – 1 – dyrekcja szkoły; 2- przeczytanie kursu teoretycznego; 3 - praca na symulatorach itp. i dla każdego typu wyniki zsumowano. Pojawił się atrybut dodatkowo opisujący rodzaj aktywności i to numeryczny. Należy go dodać do schematu relacji i uczynić atrybutem klucza podstawowego, zastępując w ten sposób długie pole znakowe.

Otrzymaliśmy diagram relacji:

PC - klucz podstawowy - numer instruktora; Kod zawodu

Konieczność normalizacji: pierwotna relacja, która jest w zerowej postaci normalnej, zawiera zbędne dane, co powoduje anomalie wstawiania - np. nie możemy wprowadzić danych o instruktorze, dopóki nie przyniesie informacji o swoim wykształceniu lub numerze rejestracyjnym i marce pojazdu przydzielony mu samochód. Zaktualizuj anomalię

Zmiana numeru rejestracyjnego samochodu (samochód został spisany) spowoduje konieczność zmiany tego pola we wszystkich wierszach, w których jest on wymieniony (zapisujemy jedynie zdjęcie chwili – kto był ostatnią osobą przypisaną do samochód, ale takich osób może być kilka i aby je zidentyfikować trzeba trochę popracować, co ma do tego praca administratora bazy danych).

Oczywista redundancja – powtórzenie nazwy rodzaju działalności.

Ukryta redundancja - zmiana tablicy rejestracyjnej pojazdu.

Kolejnym etapem prac niezbędnych do normalizacji jest określenie zależności pomiędzy atrybutami w oparciu o semantykę obszaru tematycznego.

Pobierz wykład: Nie masz dostępu do pobierania plików z naszego serwera.

Metoda tworzenia projektów, systemów, programów, w której rozwój odbywa się od góry do dołu.

Jedna z głównych metod projektowania konstrukcji. Programowanie odgórne jest szczególnym przypadkiem programowania odgórnego.

Metoda polega na sekwencyjnym dekompozycji funkcji przetwarzania danych na proste elementy funkcjonalne („od góry do dołu”).

W efekcie powstaje diagram hierarchiczny, który odzwierciedla skład i podporządkowanie poszczególnych funkcji. Nazywa się to strukturą funkcjonalną algorytmu (FSA) aplikacji, która odzwierciedla:

cele obszaru tematycznego (cel-podcel);
skład wniosków (zadań przetwarzających), które zapewniają realizację postawionych celów;
charakter interakcji aplikacji z ich głównymi cechami;
funkcje przetwarzania danych.

Przyjrzyjmy się strukturze funkcjonalnej aplikacji.

Przykład struktury funkcjonalnej aplikacji

Taka struktura odzwierciedla skład i wzajemne powiązanie funkcji przetwarzania informacji w celu wdrożenia aplikacji, nie ujawniając logiki wykonywania poszczególnych funkcji.

Rozkład musi mieć charakter ściśle funkcjonalny, tj. odrębny element FSA opisuje kompletną, znaczącą funkcję przetwarzania informacji, która zakłada określoną metodę realizacji na poziomie oprogramowania.

Funkcje wejścia/wyjścia informacji są oddzielone od obliczeniowych lub logicznych funkcji przetwarzania danych.

Niektórych funkcji, na przykład Ф2, ФМ, nie da się rozłożyć na komponenty i wymagają one bezpośredniej implementacji oprogramowania. Pozostałe funkcje (F1) można przedstawić w formie strukturalnej kombinacji więcej proste funkcje, na przykład F11, F1k. Dla wszystkich funkcji składowych przeprowadzana jest niezależna implementacja oprogramowania; funkcje złożone typu F1 są implementowane jako moduły oprogramowania kontrolujące funkcje komponentów, na przykład w postaci programów menu.

Ze względu na częstotliwość użytkowania funkcje dzielimy na jednorazowe i powtarzalne.

Literatura

Istomin E.P., Novikov V.V., Novikova M.V. Metody wysokiego poziomu informatyki i programowania: Podręcznik. - Petersburgu. LLC „Wydawnictwo Adreevsky”, 2006 - 228 s.

Rozważmy zbudowanie modelu DFD systemu informacyjnego dla sieci sklepów sprzedających torby. Uzupełnijmy wbudowany diagram IDEF0 praca laboratoryjna Schemat DFD nr 1. Zbudujmy diagram DFD dla funkcji A4 „Analizuj pracę” Patrz ryc. 4.

Ryż. 4. Przykład diagramu DFD

Ćwiczenia

Poznaj metodę DFD.
Uzupełnij model funkcjonalny systemu informacyjnego, zbudowany w pracy laboratoryjnej nr 1, o schemat przepływu danych dla tych bloków funkcjonalnych IDEF0 modelu, dla których konieczne jest pokazanie ruchu danych.
Odpowiedz na pytania testowe.
Utwórz raport (strona tytułowa, zadanie, diagram DFD)

Pytania bezpieczeństwa

Jakie procesy w systemie opisuje się za pomocą diagramów przepływu danych?
Jakie są główne obiekty diagramów przepływu danych?
Czy przy konstruowaniu diagramów DFD stosowana jest zasada dekompozycji?
Miejsce, w którym strzałka zbliża się do bloków lub miejsce, w którym strzałka wychodzi z bloku, może być dowolne lub podlegać pewnym zasadom?
W jaki sposób obiekt zostaje wyodrębniony w byt zewnętrzny?

Literatura

Fedotova, D.E. Technologie CASE: Warsztat / D.E. Fedotova, Yu.D. Semenow, K.N. Czyżyk. - M.: Infolinia– Telekomunikacja, 2005. - 160 s.: il.
Kalashyan, A.N. Strukturalne modele biznesowe: technologie DFD / A.N. Kalashyan, G.N. Kaljanow. - M.: Finanse i statystyka, 2003.
Diagramy przepływu danych DFD. - http://www.proinfotech.ru/dmdlr2.htm.
Metody modelowania procesów biznesowych. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Budowa diagramu dekompozycji w notacji DFD

Cel pracy:

skonstruuj diagram dekompozycji w notacji DFD jednego z diagramów IDEF0 skonstruowanych w poprzednich laboratoriach

Diagramy przepływu danych (DFD) służą do opisu przepływu dokumentów i przetwarzania informacji. Podobnie jak IDEF0, DFD reprezentuje modelowany system jako sieć wzajemnie powiązanych działań. Można je zastosować jako dodatek do modelu IDEF0 w celu wyraźniejszego zobrazowania bieżących operacji obiegu dokumentów 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, a także ujawnienie relacji między tymi zadaniami.

Każdy diagram DFD może zawierać działania, podmioty zewnętrzne, strzałki (przepływy danych) i magazyny danych.

Fabryka. Prace przedstawiono w formie prostokątów z zaokrąglonymi narożnikami (ryc. 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ą kontroli 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. Pojedynczy podmiot zewnętrzny może jednocześnie dostarczać dane wejściowe (pełniąc funkcję dostawcy) i przyjmować dane wyjściowe (pełniąc funkcję odbiorcy). Podmiot zewnętrzny to obiekt materialny, taki jak klienci, personel, dostawcy, klienci, magazyn. Zdefiniowanie obiektu lub systemu jako podmiotu zewnętrznego oznacza, że znajduje się on poza granicami analizowanego systemu. Podmioty zewnętrzne są przedstawiane jako prostokąt z cieniem i zwykle znajdują się na krawędziach diagramu (ryc. 2).

Rysunek 2. Podmiot zewnętrzny w DFD

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

Przechowywanie danych. W przeciwieństwie do strzałek opisujących obiekty w ruchu, hurtownie danych przedstawiają obiekty w spoczynku (rysunek 3). Hurtownia danych to abstrakcyjne urządzenie służące do przechowywania informacji, które w dowolnym momencie można umieścić na dysku i odzyskać po pewnym czasie, a sposoby przechowywania i odtwarzania mogą być dowolne. Generalnie jest to prototyp przyszłej bazy danych i opis przechowywanych w niej danych musi odpowiadać modelowi informacyjnemu (Entity-RelationshipDiagram).

Rysunek 3. Przechowywanie danych w DFD

Dekompozycja pracy IDEF0 na diagram DFD. Podczas dekompozycji pracy IDEF0 na DFD należy wykonać następujące kroki:

usuń wszystkie strzałki graniczne na diagramie DFD;
stworzyć odpowiednie podmioty zewnętrzne i magazyny danych;
utwórz strzałki wewnętrzne, zaczynając od elementów zewnętrznych zamiast strzałek granicznych;
strzałki na tunelowanym diagramie IDEF0

Nie zawsze wygodnie jest ściśle trzymać się zasad notacji DFD, dlatego BPWin umożliwia tworzenie strzałek granicznych na diagramach DFD.

Budowa diagramu rozkładu. Rozłóżmy dzieło 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:

dostarczać niezbędne komponenty- zajmuje się działaniami związanymi ze znalezieniem odpowiednich dostawców i zamówieniem u nich niezbędnych komponentów
przechowywanie komponentów i zmontowanych komputerów
wysyłka wyrobów gotowych – wszelkie czynności związane z pakowaniem, dokumentacją i faktyczną wysyłką wyrobów gotowych

Podkreślmy pracę Wysyłka i dostawa diagram A0 „Działalność przedsiębiorstwa w zakresie montażu i sprzedaży komputerów i laptopów”, kliknij na przycisk „GotoChildDiagram” na pasku narzędzi i wybierz notację DFD. Tworząc diagram podrzędny, BPWin przenosi strzałki graniczne pracy nadrzędnej, należy je usunąć i zastąpić obiektami zewnętrznymi. Strzałki mechanizmu, strzałki kontrolne „Zasady i procedury”, „Informacje zarządcze” i strzałka wyjścia „Raporty” na diagramie potomnym nie będą używane, aby nie zaśmiecać diagramu mniej istotnymi szczegółami. Pozostałe strzałki zastąpimy podmiotami zewnętrznymi - przycisk „ExternalReferenceTool” na pasku narzędzi, w oknie, które się pojawi, wybierz przełącznik „Strzałka” i wybierz żądaną nazwę z listy (ryc. 4):

Rysunek 4. Dodanie podmiotu zewnętrznego

Rysunek 5. Stanowiska pracy i podmioty zewnętrzne

Główną pracą jest tutaj „Przechowywanie komponentów i zmontowanych komputerów”. Do jego wpisu trafiają zmontowane komputery i komponenty otrzymane od dostawców, a także lista komponentów niezbędnych do złożenia komputerów. Wynikiem tej pracy będą niezbędne komponenty (jeśli są dostępne), lista brakujących komponentów przekazana na wejście pracy „Dostawa niezbędnych komponentów” oraz zmontowane komputery przekazane do wysyłki. Efektami pracy „Dostawa niezbędnych komponentów” i „Wysyłka gotowych produktów” będą odpowiednio zamówienia do dostawców i gotowe produkty.

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

Rysunek 6. Ostateczny schemat rozkładu

Praca „Dostawa niezbędnych komponentów” współpracuje z informacjami o dostawcach oraz informacjami o złożonych zamówieniach u tych dostawców. Strzałka łącząca pracę z hurtownią danych „Lista dostawców” jest dwukierunkowa, ponieważ work może zarówno otrzymywać informacje o istniejących dostawcach, jak i wprowadzać dane o nowych dostawcach. Strzałka łącząca pracę z hurtownią danych „Lista zamówień” jest jednokierunkowa, gdyż praca wprowadza jedynie informacje o złożonych zamówieniach.

Praca „Magazynowanie komponentów i zmontowanych komputerów” współpracuje z informacjami o otrzymanych i wydanych komponentach oraz zmontowanych komputerach, dlatego strzałki łączące pracę z hurtowniami danych „Lista komponentów” i „Lista zmontowanych komputerów” są dwukierunkowe. Ponadto przy tej pracy przy odbiorze komponentów należy odnotować, że zamówienie do dostawców zostało zrealizowane. W tym celu łączy się go ze składnicą danych „Lista zamówień” za pomocą jednokierunkowej strzałki. Należy pamiętać, że na diagramach DFD ten sam magazyn danych może zostać zduplikowany.

Wreszcie zadanie „Wysyłka produktów gotowych” musi przechowywać informacje o zrealizowanych wysyłkach. Aby to zrobić, wprowadź odpowiedni magazyn danych - „Dane przesyłki”.

Ostatnim krokiem jest tunelowanie strzałek pracy macierzystej (ryc. 7):

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

krótki opis rozłożone dzieło
schemat rozkładu

Przykładowy diagram DFD procesu „Opracowanie specyfikacji technologicznej” z wykorzystaniem Bpwin

Strona główna > Wykład

WYKŁAD nr 3

SCHEMATY PRZEPŁYWU DANYCH Diagramy przepływu danych(DFD) są podstawowym sposobem modelowania wymagań funkcjonalnych projektowanego systemu. Za ich pomocą wymagania te rozkładane są na komponenty funkcjonalne (procesy) i przedstawiane jako sieć połączona przepływami danych. Głównym celem takich narzędzi jest pokazanie, w jaki sposób każdy proces przekształca swoje dane wejściowe w produkty wyjściowe, a także ujawnienie relacji między tymi procesami. Diagramy przepływu danych istnieją już od bardzo dawna. Podam następujący przykład wykorzystania DFD do reorganizacji przepełnionego biura, którego historia sięga lat 20-tych. Konsultant przeprowadzający reorganizację oznaczył każdego urzędnika kółkiem, a każdy dokument przekazywany między nimi strzałką. Korzystając z takiego diagramu, zaproponował schemat reorganizacji, w którym dwóch urzędników wymieniających wiele dokumentów siedziało w pobliżu, a urzędnicy z niewielką interakcją siedzieli w dużej odległości. Tak narodził się pierwszy model, będący diagramem blokowym – zwiastunem DFD. Tradycyjnie do reprezentowania DFD używa się dwóch różnych notacji: Yourdon i Gane-Sarson. Podczas konstruowania przykładów będziemy używać notacji Yodana.

Podstawowe symbole

Główne symbole DFD pokazano na rys. 1.

R
Rys.1 Główne elementy diagramu przepływu danych

Opiszmy ich przeznaczenie. Diagramy reprezentują wymagania funkcjonalne wykorzystujące procesy i magazyny połączone przepływami danych. STRUMIEŃ DANYCH są mechanizmy stosowane do modelowania transferu informacji (lub nawet komponentów fizycznych) z jednej części systemu do drugiej. Znaczenie tego obiektu jest oczywiste: od niego pochodzi nazwa całego instrumentu. Przepływy na diagramach są zwykle reprezentowane przez nazwane strzałki, których orientacja wskazuje kierunek przepływu informacji. Czasami informacja może przemieszczać się w jednym kierunku, zostać przetworzona i wrócić do źródła. Sytuację tę można modelować albo dwoma różnymi przepływami, albo jednym – dwukierunkowym. Zamiar PROCES polega na wytwarzaniu strumieni wyjściowych ze strumieni wejściowych zgodnie z akcją określoną w nazwie procesu. Nazwa ta musi zawierać czasownik w formie nieokreślonej, po którym następuje dopełnienie (na przykład OBLICZ MAKSYMALNĄ WYSOKOŚĆ). Ponadto każdy proces musi mieć unikalny numer referencyjny na schemacie. Numeru tego można używać w połączeniu z numerem diagramu, aby zapewnić unikalny indeks procesu dla całego modelu. PRZECHOWYWANIE DANYCH pozwala zdefiniować dane w określonych obszarach, które będą przechowywane w pamięci pomiędzy procesami. W efekcie hurtownia reprezentuje „wycinki” strumieni danych w czasie. Z informacji w nich zawartych można skorzystać w dowolnym momencie po ich zdefiniowaniu, a selekcję danych można przeprowadzić w dowolnej kolejności. Nazwa repozytorium musi identyfikować jego zawartość i być rzeczownikiem. W przypadku, gdy przepływ danych wchodzi lub wychodzi z hurtowni i jego struktura jest zgodna ze strukturą hurtowni, musi mieć tę samą nazwę, której nie trzeba pokazywać na diagramie. PODMIOT ZEWNĘTRZNY (Lub TERMINATORA) reprezentuje jednostkę poza kontekstem systemu, która jest źródłem lub ujściem danych systemowych. Jej imię musi zawierać rzeczownik, np. MAGAZYN TOWARÓW, Nie oczekuje się, że obiekty reprezentowane przez takie węzły będą uczestniczyć w jakimkolwiek przetwarzaniu. Diagram kontekstowy i szczegóły procesu Dekompozycja DFD opiera się na procesach: każdy proces można rozszerzyć za pomocą DFD niższego poziomu. Szczególną rolę w modelu odgrywa specjalny typ DFD - diagram kontekstowy, modelowanie systemu w najbardziej ogólny sposób. Diagram kontekstu odzwierciedla interfejs systemu ze światem zewnętrznym, czyli przepływ informacji pomiędzy systemem a podmiotami zewnętrznymi, z którymi musi być połączony. Identyfikuje te podmioty zewnętrzne, a także zwykle pojedynczy proces, który w jak największym stopniu odzwierciedla główny cel lub naturę systemu. I choć diagram kontekstu wydaje się banalny, to jego niewątpliwa użyteczność polega na tym, że wyznacza granice analizowanego systemu. Każdy projekt powinien mieć dokładnie jeden diagram kontekstu i nie ma potrzeby numerowania jego jedynego procesu. DFD pierwszego poziomu jest budowane jako dekompozycja procesu obecnego na diagramie kontekstu. Skonstruowany diagram pierwszego poziomu ma również wiele procesów, które z kolei można rozłożyć na DFD niższego poziomu. Spowoduje to utworzenie hierarchii DFD z diagramem kontekstu w korzeniu drzewa. Ten proces dekompozycji trwa do momentu, gdy procesy będą mogły być efektywnie opisane przy użyciu krótkich (do jednej strony) specyfikacji miniprocesu (specyfikacje procesu). Dzięki takiej konstrukcji hierarchii DFD każdy proces jest czymś więcej niski poziom musi być skorelowany z procesem wyższego szczebla. W tym celu stosuje się zazwyczaj ustrukturyzowane numery procesów. Na przykład, jeśli wyszczególnimy proces numer 2 na diagramie pierwszego poziomu, rozszerzając go za pomocą DFD zawierającego trzy procesy, wówczas ich numery będą następny widok: 2.1, 2.2 i 2.3. W razie potrzeby możesz przejść na kolejny poziom, tj. dla procesu 2.2 otrzymujemy 2.2.1, 2.2.2. itp. Zilustrujmy diagram kontekstu przykładem. P

przykład . Przyjrzyjmy się procesowi ZDAWANIA EGZAMINU. Mamy dwa podmioty STUDENT i NAUCZYCIEL. Opiszmy przepływy danych, które nasz zaprojektowany system wymienia z obiektami zewnętrznymi.

Od strony STUDENTA opiszemy przepływy informacji. Do zdania egzaminu konieczne jest posiadanie ZALICZENIA oraz DOPUSZCZENIE DO EGZAMINU. Wynik zdania egzaminu, tj. strumieniami wyjściowymi będą OCENA EGZAMINU i TEST, w którym zostanie wpisana OCENA. Od strony NAUCZYCIELA przepływ informacji wygląda następująco. PROTOKÓŁ Z EGZAMINU, z którego będzie wiadomo, że STUDENT został dopuszczony do egzaminu, a także dokument urzędowy, w którym będzie wpisany wynik egzaminu, tj. OCENA Z EGZAMINU ZAWARTA W RAPORTIE. Teraz opiszmy szczegółowo proces 1. ZDANIE EGZAMINU. Proces ten będzie obejmował następujące procesy:

Narysuj bilet Przygotuj się na odpowiedź Odpowiedzi na zgłoszenie Ocena

Dekompozycja danych i powiązane rozszerzenia diagramów przepływu danych

Poszczególne dane w systemie są często niezależne. Czasami jednak konieczne jest radzenie sobie z kilkoma niezależnymi danymi jednocześnie. Na przykład system ma wątki JABŁKA, POMARAŃCZE I GRUSZKI. Wątki te można pogrupować wprowadzając nowy wątek OWOCE. W tym celu konieczne jest formalne zdefiniowanie przepływu OWOCE jako składający się z kilku elementów potomnych. Definicja ta jest podana za pomocą Formularze Backusa-Naura (BNF) w słowniku danych (tej formie przyjrzymy się w następnym wykładzie). Z kolei przepływ OWOCE sam może być zawarty w wątku nadrzędnym ŻYWNOŚĆ wraz ze strumieniami WARZYWA, MIĘSO itp. Takie przepływy, łączące kilka przepływów, nazywane są grupa Odwrotna operacja, polegająca na podziale przepływów na podprzepływy, realizowana jest za pomocą węzła grupowego (rys. 3), który pozwala na podział strumienia na dowolną liczbę podprzepływów.

R

Jest. 3

Podczas podziału konieczne jest także formalne zdefiniowanie podstrumieni w słowniku danych (za pomocą BNF). W podobny sposób przeprowadza się dekompozycję przepływów przez granice diagramów, co pozwala na uproszczenie szczegółowego DFD. Niech będzie przepływ OWOCE, uwzględnione w szczegółowym procesie. Schemat blokowy szczegółowo opisujący ten proces OWOCE może w ogóle nie istnieć, ale zamiast tego mogą istnieć wątki JABŁKA I POMARAŃCZE(jakby zostały przeniesione z uszczegóławianego procesu). W tym przypadku musi istnieć definicja przepływu BNF OWOCE, składający się z podpływów JABŁKA I POMARAŃCZE, dla celów bilansowania. Zastosowanie tych operacji na danych pozwala na strukturyzację danych oraz zwiększa widoczność i czytelność diagramów. Aby zapewnić dekompozycję danych i inne możliwości usług, dodano DFD następujące typy obiekty: 1) WĘZEŁ GRUPY. Przeznaczony do dzielenia i łączenia strumieni. W niektórych przypadkach może go nie być (tj. faktycznie zdegenerować się do punktu łączenia/rozdzielania przepływów na diagramie). 2) WĘZEŁ Przodka . Umożliwia łączenie przepływów przychodzących i wychodzących pomiędzy procesem opisywania szczegółów a szczegółowym DFD. 3) NIEUŻYWANY WĘZEŁ . Stosuje się go w sytuacji, gdy dekompozycja danych odbywa się w węźle grupowym i nie wszystkie elementy strumienia wchodzącego do węzła są wymagane. 4) ZMIEŃ NAZWĘ WĘZŁA . Pozwala na niejednoznaczne nazywanie strumieni, przy równoczesnej ich zawartości. Przykładowo, jeśli podczas projektowania różnych części systemu ten sam fragment danych otrzymał różne nazwy, to równoważność odpowiednich przepływów danych zapewnia węzeł zmiany nazwy. W tym przypadku jeden z przepływów
dane są wejściem dla tego węzła, a drugie jest wyjściem.

Tekst w dowolnym formacie w dowolnym miejscu na wykresie. Możliwy sposób przedstawienia tych węzłów pokazano na ryc. 3.

Budowa modelu

Głównym celem konstruowania hierarchicznego zestawu DFD jest uczynienie wymagań jasnymi i zrozumiałymi na każdym poziomie szczegółowości oraz podzielenie tych wymagań na części z precyzyjnie określonymi relacjami między nimi. Aby to osiągnąć, zaleca się skorzystanie z następujących zaleceń:

zdrowy rozsądek

Zgodnie z tymi zaleceniami proces budowy modelu dzieli się na następujące etapy:

Rozbicie wielu wymagań i zorganizowanie ich w główne grupy funkcjonalne.

Identyfikacja obiektów zewnętrznych, z którymi system powinien być połączony.

Identyfikacja głównych typów informacji krążących pomiędzy systemem a obiektami zewnętrznymi. Wstępne opracowanie diagramu kontekstu, w którym główne grupy funkcjonalne są reprezentowane przez procesy, obiekty zewnętrzne - przez podmioty zewnętrzne, główne rodzaje informacji - przez przepływy danych pomiędzy procesami i podmiotami zewnętrznymi. Przestudiuj wstępny diagram kontekstu i wejdź
zmiany w nim na podstawie wyników reakcji na otrzymane
studiowanie pytań we wszystkich ich częściach. Konstruowanie diagramu kontekstu poprzez połączenie wszystkich
wstępnie scharakteryzować procesy w jeden proces, oraz
grupowanie wątków. Generowanie DFD pierwszego poziomu w oparciu o wstępne procesy diagramu kontekstu. Weryfikacja podstawowych wymagań dla DFD poziomu 1. Dekompozycja każdego procesu bieżącego DFD przy użyciu szczegółowego diagramu lub specyfikacji procesu. Weryfikacja podstawowych wymagań dla DFD na odpowiednim poziomie. Dodawaj nowe definicje strumieni do słownika danych, gdy tylko pojawią się na wykresach. Równolegle z procesem dekompozycji badanie wymagań (w tym nowo otrzymanych), rozbicie ich na elementarne i zidentyfikowanie procesów lub specyfikacji procesów spełniających te wymagania. Po zbudowaniu dwóch lub trzech poziomów przeprowadzamy audyt mający na celu sprawdzenie poprawności i poprawę zrozumiałości modelu. Konstrukcja specyfikacji procesu (a nie prostego diagramu) w przypadku, gdy dana funkcja jest trudna lub niemożliwa do wyrażenia poprzez kombinację procesów.

Rozszerzenia w czasie rzeczywistym

Rozszerzenia czasu rzeczywistego służą do uzupełnienia modelu funkcjonowania danych (hierarchii DFD) o narzędzia opisujące aspekty sterowania w systemach czasu rzeczywistego. W tym celu stosuje się następujące symbole (ryc. 4):

1) PROCES KONTROLI. Reprezentuje interfejs pomiędzy DFD a specyfikacjami sterowania, które faktycznie modelują i dokumentują aspekty w czasie rzeczywistym. Jego nazwa wskazuje rodzaj działania kontrolnego wynikającego ze specyfikacji. W rzeczywistości proces sterowania polega na przetwarzaniu wejściowych strumieni sterujących na wyjściowe strumienie sterujące; w tym przypadku dokładny opis tej transformacji musi być podany w specyfikacji sterowania. 2) MAGAZYN ZARZĄDZANIA. Reprezentuje „wycinek przepływu sterowania w czasie. Informacje sterujące, które zawiera, mogą zostać użyte w dowolnym momencie po zapisaniu ich w magazynie, a odpowiadające im dane mogą być użyte w dowolnej kolejności. Nazwa magazynu kontrolnego musi identyfikować jego zawartość i być rzeczownikiem. Magazyn kontrolny różni się od tradycyjnego tym, że może zawierać tylko przepływy kontrolne, wszystkie inne cechy są identyczne. 3) PRZEPŁYW KONTROLI to „rura”, przez którą przepływają informacje sterujące tylko rzeczowniki i przymiotniki wartość dyskretna, a nie ciągła. Może to być na przykład sygnał reprezentujący stan lub rodzaj operacji. Logiczny proces sterowania to pewien punkt poleceń, który reaguje na zmiany warunków zewnętrznych przekazywanych mu za pomocą sterowania przepływa i produkuje zgodnie ze swą wewnętrzną logiką wykonywaną przez procesy. W tym przypadku tryb wykonania procesu zależy od rodzaju wątku sterującego. Dostępne są następujące typy przepływów kontrolnych: a) Przepływ T (przepływ wyzwalający). Jest wątkiem kontroli procesu, który może spowodować wykonanie procesu. W tym przypadku proces wydaje się być uruchomiony w jednej krótkiej operacji. Jest to odpowiednik włącznika światła, którego pojedyncze naciśnięcie rozpoczyna proces spalania lampy. b) Przepływ A (przepływ aktywatora). Jest wątkiem sterującym procesem, który może modyfikować wykonanie pojedynczego procesu. Służy do zapewnienia ciągłości wykonywania procesu tak długo, jak wątek jest „włączony” (tj. przepływa w sposób ciągły), gdy wątek jest „wyłączony”, wykonywanie procesu się kończy. Jest to analogiczne do włącznika lampy, który może być włączony lub wyłączony. V) E/D-przepływ(włącz/wyłącz przepływ). Jest wątkiem sterującym procesem, który może przełączyć wykonanie oddzielnego procesu. Przepływ wzdłuż linii E powoduje wykonanie procesu, który trwa do momentu zainicjowania przepływu wzdłuż linii D. Jest to analogia przełącznika z dwoma przyciskami: jednym do włączania światła, drugim do wyłączania. Pamiętaj, że możesz używać 3 typów takich strumieni: E-stream, D-stream, E/D-stream. Czasami istnieje potrzeba reprezentowania tego samego fragmentu danych za pomocą strumieni różne typy. Na przykład strumień danych PRĘDKOŚĆ POJAZDU w w niektórych przypadkach może być używany jako kontrola do kontrolowania wartości krytycznej. Aby to zapewnić, wykorzystuje się WĘZEŁ ZMIANY TYPU (rys. 5): strumień danych jest wejściem dla tego węzła, a strumień sterujący jest wyjściem.

Ryż. 5. Węzeł zmiany typu

Diagramy przepływu danych (DFD) są głównym sposobem modelowania wymagań funkcjonalnych projektowanego systemu. Za ich pomocą wymagania prezentowane są w formie hierarchii komponentów funkcjonalnych (procesów) połączonych przepływami danych. Głównym celem takiej reprezentacji jest pokazanie, w jaki sposób każdy proces przekształca swoje dane wejściowe w produkty wyjściowe, a także ukazanie relacji między tymi procesami.

Do konstruowania diagramów EGO stosuje się dwie różne notacje, odpowiadające metodom Jordana i Gaina-Sarsona, które nieznacznie się różnią obrazy graficzne pismo. Ponadto przy konstruowaniu przykładów zostanie zastosowana notacja Hein-Sersona. Konstrukcja diagramów BDE wiąże się głównie z rozwojem systemów oprogramowania i do tych celów pierwotnie opracowano notację BDE.

Zgodnie z tymi metodami model systemu definiuje się jako hierarchię przepływów danych opisującą asynchroniczny proces przekształcania informacji od jej wprowadzenia do systemu aż do dostarczenia użytkownikowi. Diagramy na najwyższych poziomach 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. Rozkład ten trwa, tworząc wielopoziomową hierarchię diagramów, aż do osiągnięcia poziomu rozkładu, na którym procesy stają się elementarne, tak że nie można ich dalej uszczegóławiać.

Źródła informacji (podmioty zewnętrzne) generować przepływy informacji (strumienie danych), przekazywanie informacji 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, urządzeń przechowujących dane lub podmiotów zewnętrznych – konsumentów informacji.

Główne elementy diagramów OGB to:

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

Byty zewnętrzne to obiekty materialne lub indywidualny, który jest źródłem lub odbiorcą informacji, na przykład klient, personel, dostawca, klient, magazyn. Zdefiniowanie obiektu lub systemu jako podmiotu zewnętrznego oznacza, że znajduje się on poza granicami analizowanego systemu. W procesie analizy, jeśli zajdzie taka potrzeba, niektóre podmioty zewnętrzne mogą zostać przeniesione wewnątrz diagramu analizowanego systemu lub odwrotnie, niektóre procesy mogą zostać przeniesione poza diagram i przedstawione jako byt zewnętrzny.

Byt zewnętrzny jest oznaczony kwadratem (ryc. 5.12), umieszczonym jakby nad diagramem 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 jak najbardziej przedstawić widok ogólny na tzw. diagramie kontekstowym w formie jednego

system jako całość lub można go rozłożyć na kilka podsystemów (ryc. 5.13).

Ryż. 5.12.

Identyfikator

Polenometr

Pole nazwy pola

fizyczny

realizacja

Ryż. 5.13. Schemat kontekstowy

Numer podsystemu służy do jego identyfikacji. W polu nazwa należy wpisać nazwę podsystemu w formie zdania z podmiotem oraz odpowiadającymi mu definicjami i dodatkami.

Proces reprezentuje transformację strumieni danych wejściowych na wyjściowe zgodnie z określonym algorytmem. Proces ten można wdrożyć fizycznie na różne sposoby: może to być oddział (dział) organizacji zajmujący się określonym przetwarzaniem dokumentów wejściowych i wystawianiem raportów, program, urządzenie fizyczne realizowane sprzętowo itp. Proces na schemacie jest przedstawiony jako prostokąt z zaokrąglonymi narożnikami (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 nazwa wpisz nazwę procesu w formie zdania z czasownikiem czynnym, jednoznacznym w formie nieokreślonej („oblicz”, „sprawdź”, „oblicz”, „utwórz” itp.), a następnie dopisz rzeczownik w bierniku (ryc. 5.14). Używanie czasowników takich jak „proces”, „aktualizacja” lub „edycja” wskazuje na brak zrozumienia ten proces i wymaga dalszej analizy. Informacje w polu fizycznej implementacji wskazują, który dział, program lub urządzenie wykonuje proces.

Przechowywanie danych to abstrakcyjne urządzenie służące do przechowywania informacji, które w każdej chwili można umieścić na nośniku i po pewnym czasie odtworzyć, a sposoby przechowywania i odtwarzania mogą być dowolne. Dysk danych (pamięć) można zaimplementować fizycznie w formie tabeli BARAN, plik na dysku magnetycznym, pudełko w szafce na dokumenty itp. Magazyn danych na schemacie jest oznaczony literą I i dowolną liczbą. Nazwę napędu wybiera się tak, aby była najbardziej informacyjna dla projektanta (ryc. 5.15).

identyfikacja

Pole nazwy

Ryż. 5.15. Obraz przechowywania danych

Nośnik danych w ogólnym przypadku jest prototypem przyszłej bazy danych; opis przechowywanych w nim danych musi być powiązany z modelem informacyjnym (IML). 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 przenoszone z jednego komputera na drugi itp. Każdy strumień ma nazwę odzwierciedlającą jego zawartość (rysunek 5.16).

Generuj raporty dotyczące podatku dochodowego

raportowanie

Raportowanie

podatek dochodowy

Ryż. 5.16.

Połączenia w diagramach PBP można dzielić (rozwidlać) na części, a każdemu powstałemu segmentowi można nadać nazwę w taki sposób, aby pokazać dekompozycję danych niesionych przez jakiś przepływ (rys. 5.17). Strzałki można łączyć ze sobą (kombinować) tworząc złożone obiekty. Przykładowo, aby wygenerować adres podatnika, trzeba mieć dane o jego elementach (kod pocztowy, miejscowość, ulica, numer domu i numer lokalu).

Zapisz adres podatnika

Dział Księgowości Podatników

Ryż. 5.17.

Używając diagramów BEM do modelowania wymagań funkcjonalnych dla systemu oprogramowania, tworzona jest hierarchia diagramów w celu zapewnienia przejrzystości i wygody projektanta. 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 odbywa się równolegle z dekompozycją procesów;
Wybierz jasne, opisowe nazwy procesów i wątków i unikaj używania skrótów.

Pierwszym krokiem w konstruowaniu hierarchii diagramów przepływu danych jest skonstruowanie diagramów kontekstowych, które pokazują, w jaki sposób zaprojektowany system będzie współdziałał z użytkownikami i innymi osobami. systemy zewnętrzne(pewna analogia przypadków użycia w podejściu obiektowym). Przy projektowaniu stosunkowo prostych systemów wystarczy pojedynczy diagram kontekstowy o topologii gwiazdy, w centrum którego znajduje się proces główny, powiązany ze źródłami i odbiorcami informacji.

Dla złożone systemy Konstruowana jest hierarchia diagramów kontekstowych, która określa interakcję głównych podsystemów funkcjonalnych projektowanego systemu zarówno między sobą, jak i z zewnętrznymi strumieniami danych wejściowych i wyjściowych oraz obiektami zewnętrznymi. W tym przypadku diagram kontekstu najwyższego poziomu zawiera zbiór podsystemów połączonych przepływami danych. Następny poziom diagramów kontekstowych szczegółowo opisuje zawartość i strukturę podsystemów.

Po skonstruowaniu diagramów kontekstowych powstały model należy sprawdzić pod kątem kompletności danych wyjściowych o obiektach systemu oraz izolacji obiektów (brak powiązań informacyjnych z innymi obiektami). Każdy podsystem obecny 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, magazynami danych, podmiotami zewnętrznymi, łączami do innych procesów w celu opisania powiązań między tym procesem a jego otoczeniem.

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

zasada równoważenia, która oznacza, że przy opisywania podsystemu można wykorzystać tylko te komponenty (podsystemy, procesy, podmioty zewnętrzne, dyski danych), z którymi ma on połączenie na schemacie nadrzędnym;
zasada numeracji, która mówi, że przy opisywania procesów należy zachować ich hierarchiczną numerację.

Specyfikacja procesu powinien tak formułować swoje główne funkcje, 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 dokończeniu uszczegółowienia procesu 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);
umiejętność opisu transformacji danych przez proces w postaci algorytmu sekwencyjnego;
wykonanie w procesie pojedynczej funkcji logicznej polegającej na konwersji informacji wejściowych na dane wyjściowe;
możliwość opisania logiki procesu za pomocą małej specyfikacji (nie więcej niż 20-30 linii).

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

musi istnieć jedna (i tylko jedna) specyfikacja dla każdego procesu niższego poziomu;
specyfikacja musi definiować, w jaki sposób strumienie wejściowe są konwertowane na strumienie wyjściowe;
nie ma potrzeby (przynajmniej na etapie generowania wymagań) ustalania sposobu realizacji tej transformacji;
specyfikacja powinna dążyć do ograniczenia redundancji: nie powinna redefiniować tego, co zostało już zdefiniowane na schemacie;
zbiór konstrukcji specyfikacji konstrukcyjnych powinien być prosty i zrozumiały.

Tak naprawdę specyfikacja jest opisem algorytmów zadań realizowanych przez procesy. Specyfikacje zawierają numer i (lub) nazwę procesu, listę danych wejściowych i wyjściowych oraz treść (opis) procesu, czyli specyfikację algorytmu lub operacji przekształcającej strumienie danych wejściowych w wyjściowe. Znany duża liczba różnorodne metody opisu istoty procesu. Języki odpowiadające tym metodom mogą obejmować ustrukturyzowany język naturalny lub pseudokod, a także języki projektowania wizualnego.

Strukturalny język naturalny służy do opisu specyfikacji procesu w czytelny i wystarczająco rygorystyczny sposób. Taki język składa się z podzbioru słów zorganizowanych w specyficzne struktury logiczne, wyrażenia arytmetyczne i diagramy. Struktury sterujące języka obejmują konstrukcję sekwencyjną, konstrukcję selekcji i iterację (pętlę).

W przypadku stosowania strukturalnego języka naturalnego akceptowane są następujące konwencje:

logika procesu jest wyrażona jako kombinacja konstrukcji sekwencyjnych, konstrukcji wyboru i iteracji;
czasowniki powinny być aktywne, jednoznaczne i zorientowane na działanie (na przykład „wypełnij”, „oblicz”, „wyodrębnij”, a nie „uaktualnij”, „proces”);
Logika procesu musi być wyrażona jasno i jednoznacznie.

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

uszczegółowienia procesu należy dokonać dopiero po zdefiniowaniu struktur danych opisujących zawartość wszystkich przepływów i urządzeń przechowujących dane. Struktury danych mogą zawierać alternatywy, wystąpienia warunkowe i iteracje. Alternatywa oznacza, że konstrukcja może zawierać jeden z wymienionych elementów. Wystąpienie warunkowe wskazuje, że dany komponent może nie występować w konstrukcji. Iteracja polega na wprowadzeniu dowolnej liczby elementów z zadanego zakresu.

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

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

Być może zainteresują Cię poniższe materiały