Modele zachowania

Model zachowania (model behawioralny) opisuje wewnętrzne zachowanie syste-mu w odpowiedzi na bodźce z otoczenia zewnętrznego, zobrazowanego za pomocą modelu środowiska. Inaczej mówiąc, model zachowania w postaci diagramu DFD obrazuje, w jaki sposób obiekty zewnętrzne (terminatory), procesy i magazyny danych są ze sobą powiązane, jakich transformacji danych wejściowych na dane wyjściowe dokonuje system, dokąd dostarczane są wyniki. Metoda budowania modelu zachowa-nia za pomocą pakietu ProcessAnalyst opiera się na klasycznym podejściu zstępują-cym (top-down). Istota tej metody polega na dekomponowaniu pojedynczego procesu występującego na diagramie kontekstowym i reprezentującego cały system na podsys-temy, czyli procesy realizujące poszczególne funkcje systemu. Dekompozycja

po-szczególnych procesów odbywa się do momentu osiągnięcia poziomu procesów ele-mentarnych. Otrzymane diagramy przepływu danych, uporządkowane hierarchicznie poziomami, reprezentują główne składowe funkcjonalne systemu, nie zawierają jed-nak informacji szczegółowych. Kompletny model zachowania oprócz diagramu DFD wymaga utworzenia słownika danych, czyli uporządkowanego wykazu wszystkich danych mających związek z systemem oraz dokonania specyfikacji procesów. Należy pamiętać, że tylko procesy elementarne opisywane są za pomocą specyfikacji mają-cych charakter opisu algorytmicznego. Metody notacji dla słownika danych oraz spe-cyfikacji procesów omówiono w dalszej części rozdziału.

Rys. 6.8. Symbol narzędzia umożliwiającego dekompozycję procesu Narzędzie dekompozycji

Dekompozycji procesu głównego w polu projektu programu ProcessAnalyst doko-nuje się narzędziem dekompozycji znajdującym się na palecie narzędzi (rys. 6.8) lub przez użycie prawego przycisku myszki i wybranie z menu wyskakującego polecenia

Decompose. Program otwiera nowe okno projektu, w którym widoczne będą wszystkie

terminatory wraz z dołączonymi przepływami danych migrującymi z poziomu wyższego.

Rys. 6.9. Widok pola projektu po dekompozycji procesu głównego z przykładu 6.1

Następnym krokiem w procesie budowy diagramu DFD jest umieszczenie w mo-delu podprocesów wchodzących w skład procesu głównego. Podprocesy muszą być dołączone do przepływów widocznych w modelu. Zanim więc projektant użyje

narzę-dzia dekompozycji, powinien dokładnie przemyśleć, jakie podprocesy wchodzą w skład procesu nadrzędnego. W tym momencie jasna staje się rola i zadania narzę-dzia CASE – wspomaganie analityka czy projektanta, ale nie wyręczanie w pracy koncepcyjnej. Biorąc pod uwagę aspekt techniczny postępowania, w modelu z przy-kładu 6.1 został umieszczony symbol podprocesu generowania raportów, których żąda kierownictwo firmy. Podproces generowania raportów musi być związany z dwoma przepływami danych łączącymi obiekt zewnętrzny, jakim jest kierownictwo firmy z planowanym podprocesem generującym raporty dotyczące sprzedaży towarów.

Rys. 6.10. Fragment modelu dla przykładu 6.1 z podprocesem generowania raportów

Jeśli projektant decyduje, że podproces nie będzie podlegał dalszej dekompozycji, czyli że jest to proces elementarny, należy tę decyzję zaznaczyć w oknie definicji pro-cesu wybierając opcję Lowest level (rys. 6.11).

Rys. 6.11. Wybór poziomu dekompozycji w definicji podprocesu

Zgodnie z definicją, przepływy danych obrazują ruch danych w systemie, czyli między elementami modelu. Inaczej mówiąc, przepływy danych reprezentują związki

między procesami (funkcjami systemu). Przepływy mogą transportować pojedyncze elementy danych lub całe pakiety danych składające się z pojedynczych elementów. Na obecnym etapie tworzenia modelu przepływy mają jedynie swoje nazwy, które reprezentują znaczenie pakietów poruszających się wzdłuż przepływu. Program Pro-cessAnalyst wymaga, aby z każdym przepływem związane zostały faktyczne elementy danych, inaczej podczas sprawdzania modelu pojawią się komunikaty ostrzegające, że przepływ jest pusty (nie przenosi danych). Kolejnym etapem tworzenia modelu jest więc zdefiniowanie elementów danych związanych z systemem oraz dziedzin danych identyfikujących typ elementu danych, a następnie przypisanie elementów danych do odpowiednich przepływów. Definiowanie danych elementarnych odbywa się poprzez wybór z menu polecenia Dictionary →List of Data Items, co powoduje pojawienie się okna dialogowego umożliwiającego definiowanie danych (rys. 6.12).

Rys. 6.12. Definiowanie elementów danych za pomocą okna dialogowego

Po zdefiniowaniu danych elementarnych można je przyłączyć do odpowiednich przepływów, uwzględniając bardzo istotną uwagę: procesy i przepływy danych są

obiektami lokalnymi – należą do określonego poziomu diagramu, natomiast

termina-tory i magazyny danych są obiektami globalnymi – występują na każdym poziomie dekompozycji.

Po określeniu elementów danych można na każdym poziomie dekompozycji skoja-rzyć odpowiednie elementy danych z przepływem. Odbywa się to poprzez urucho-mienie edycji przepływu podwójnym kliknięciem myszki, powodującym otwarcie okna dialogowego, z zakładką Data Items (rys. 6.13).

Rys. 6.13. Okno dialogowe umożliwiające skojarzenie elementów danych z przepływem

Kolejnymi obiektami, które wchodzą w skład modelu są magazyny danych repre-zentujące dane w spoczynku. Inaczej mówiąc, magazyny danych są zbiorami (bardzo często są to pliki bazy danych), na których działają procesy, odczytując, modyfikując lub zapisując dane. Powiązanie między procesem a magazynem danych reprezentuje przepływ danych, zrozumiały więc jest sposób działania pakietu ProcessAnalyst umożliwiający w automatyczny sposób „umieszczenie” danych przenoszonych przez przepływ w docelowym magazynie. Taki sposób „wypełniania” magazynów danych wymaga ustawienia odpowiedniej opcji modelu w menu File. Okno dialogowe umoż-liwiające wybór automatycznego wypełniania magazynów zostało przedstawione na rysunku 6.3 – ustawienia opcji Auto Fill dokonuje się w panelu Data Stores.

Na każdym etapie budowania modelu można sprawdzać jego poprawność, wyko-rzystując opcję menu Dictionary → Check model. Należy pamiętać, że pakiet spraw-dza poprawność modelu pod względem formalnym, a nie logicznym, tzn. czy procesy mają wejścia i wyjścia, czy z przepływami danych związane są pakiety lub elementy danych, czy przepływy danych są związane z innymi obiektami modelu itp. W przy-padku wykrycia błędów tego typu drukowane są komunikaty o błędach i ostrzeżenia. Mechanizmem ułatwiającym kontrolę logiczną modelu jest tworzona automatycznie przez pakiet macierz krzyżowa, tzw. macierz CRUD (rys. 6.20).

Na kolejnych stronach zamieszczono wybrane diagramy DFD, będące wynikiem dekompozycji diagramów kontekstowych omawianych w pierwszej części rozdziału.

Kontynuacja przykładu 6.2 – diagram DFD dla systemu SSKF

Satus wykonania Dane do raportow [Zgloszenie kasy] Dane zlecenia Dane do przegladu Terminy zlecen

[Raporty o pracy serwisu]

Dane do dialogu

Id Klienta

Id kasy Rezygnacja z przegladu

Informacja o terminie przegladu

Aktualizacja danych kasy Uaktualnienie danych Wymogi przegladu [Wystawienie faktury] Potwierdzenie realizacji [Zlecenie] Dane kasy Dane klienta Dane Kierownictwo Klienci Klienci Serwisanci 1.1 Zgloszenie kasy ^Klienci Kasy 1.2 Okreslenie terminu realizacji 1.3 Potwierdzenie wykonania 1.4 Sprawdzenie terminow przegladow 1.5 Tworzenie raportow o pracy serwisu 1.6 Dialog z klientem Zlecenia

Rys. 6.14. Diagram ogólny dla systemu SSKF (diagram DFD poziomu 0)

Kontynuacja przykładu 6.4 – diagramy DFD dla Systemu Zarządzania Magazynem

cena towarow

Wskazniki min max dopuszczalne poziomy towarow

aktualny stan aktualizacja stanu

dane operacji na towarach operacje na towarach

dane do statystyk o towarach wysylanych dane wysylanych towarow

Parametry konfiguracji raportu

konfiguracja raportow Czestotliwosc agregacji

Czestotliwosc agregacji danych [Informacje o dostawie] [komunikaty stanu produktu]

[cena towaru]

[Raporty sprzedazy]

[dane podlegajace agregacji] [Raporty zestawienia]

[Parametry dostawcy] [Dane o dostawacach towarach limitach]

[sprzedana ilosc] [komunikaty stanu towaru] [Dane o przyjmowanym towarze]

[Dane o uszkodzeniach towarow]

[Lista roznic] [Lista inwentaryzacyjna] Magazynier zy Magazynierzy Komisja inwentaryzacyjna Komisja inwentaryzacyjna Pracownicy biurowi Pracownicy biurowi Dostawcy Dostawcy Dostawcy Dostawcy Analitycy Archiwizacja System sprzedazy System sprzedazy 1.1 Uaktualnianie stanu + 1.2 Statystyka i archiwizacja + 1.3 Konfiguracja systemu + Raporty Agregacje Awizacja Dane statystyczne Stany magazynowe Limity cennik

Rys. 6.15. Diagram ogólny Systemu Zarządzania Magazynem – pierwszy poziom dekompozycji

Uwagi:

1.1. Uaktualnianie stanu – proces (podsystem) zapewniający poprawność stanów