Tworzenie raportów o pracy serwisu IF (data systemowa > 27 danego miesiąca)

SEND przekazanie serwisowi zlecenia TO TERMINATOR Serwisanci }

} WHILE (!termin)

1.3. Potwierdzenie wykonania

GET potwierdzenie wykonania FROM TERMINATOR Serwisanci AS potwierdzenie IF (potwierdzenie)

{

SEND wysłanie rachunku TO TERMINATOR Klient SET data_ostatniego_przegladu AS aktualna_data SAVE data_ostatniego_przeglądu TO STORE Kasy }

1.4. Sprawdzenie terminów przeglądów

GET Nr_unikatowy + Data_ostatniego_przeglądu + Adres_instalacji FROM STORE Kasy

IF (Data_ostatniego_przeglądu > (Data_ustawowa – 7 dni) {

SEND sygnał „kasa wymaga przeglądu” TO PROCESS 1.2 Określenie termi-nu realizacji

}

1.5. Tworzenie raportów o pracy serwisu IF (data systemowa > 27 danego miesiąca) {

FOR Serwisanci { DO

{

FIND Serwisant, data_realizacji, status) FROM STORE Zlecenia IF (data_realizacji = bieżący miesiąc AND status = T)

} WHILE TRUE

}

Kontynuacja przykładu 6.4 – specyfikacja niektórych procesów dla Systemu

Zarzą-dzania Magazynem wzorowana na składni języka C/C++ (rys 6.18, procesy związane ze statystyką i archiwizacją). Do zbioru słów kluczowych włączono foreach (obiekt in

obiek-ty), powodujące za każdym wykonaniem pętli podstawienie pod zmienną obiekt kolejno

każdego obiektu ze zbioru obiektów. Magazyny danych są zaznaczone przez podkreśle-nie.

1.2.1. Generowanie statystyk dla dostawców

Opis: Proces generuje zestawienia statystyczne (raporty) dla jednego dostawcy. Wejście: Id_dostawcy

Wyjście: raport Algorytm:

FOREACH (raport IN Raporty.Zapytanie (kod_raportu = Dostawcy, Id_dostawcy)) GENERUJ Statystyki (raport)

1.2.2. Generowanie statystyk przekrojowych

Opis: Proces generuje statystyki dla konkretnych konfiguracji raportu Wejście: parametry konfiguracji

Wyjście: raport Algorytm:

Id_producenta = raport.Id_producenta; Id_towaru = raport.Id_towaru;

Dane = Dane Statystyczne.Zapytanie (Id_producenta, Id_towaru); SWITCH (raport.Postać_raportu)

{ CASE SPRZEDAŻ:

operacja = Operacje.Zapytanie (SPRZEDAŻ); Id_operacji = operacja.Id_poeracji;

FOREACH (dana IN dane) {

IF (dana.Data >= aktualnaData – raport.okres && Dana.Id_operacji == Id_operacji)

}

PRINT (dana.Data, dana.Godzina, dana.ilość); } } BREAK; CASE USZKODZENIA: { IF (stan.Data_ważności < AktualnaData) Przeterminowane += stan; } }

RETURN przeterminowane

Pokazane przykłady obrazują sposób specyfikacji procesów za pomocą struktural-nego języka polskiego, zawierają opis procedur prowadzących od danych do wyni-ków. Sposób ten jest zalecany w przypadkach, gdy związki między danymi wejściowymi i wynikami są złożone. Należy jednak zauważyć, że specyfikacje muszą być czytelne dla użytkownika, a więc nie mogą być zbyt skomplikowane (zbyt wiele poziomów zagnieżdżenia, nieczytelny układ edytorski, zbyt obszerne). Jeśli specyfi-kacje opracowane w takiej konwencji stają się bardzo złożone, należy zastanowić się nad inną metodyką specyfikacji procesów lub wręcz przeanalizować powtórnie dia-gram DFD pod kątem dalszej dekompozycji procesów.

W przypadku, gdy funkcja realizowana przez proces może być wykonywana na kilka sposobów, specyfikacje procesów powstają poprzez określenie tzw. warunków

początkowych i końcowych, bez precyzowania poszczególnych algorytmów. Warunki

początkowe określają wszystko, co musi być spełnione przed rozpoczęciem procesu (dane wejściowe, związki między różnymi magazynami lub wewnątrz określonego magazynu), warunki końcowe określają stan po zakończeniu działania procesu (opis wyników, zmiany dokonane w magazynach, związki między wynikami a wartościami w magazynach). Należy pamiętać, że stosując taką metodę specyfikacji należy sprecy-zować, oprócz warunków początkowych i końcowych dla sytuacji normalnych, wa-runki początkowe i końcowe dla sytuacji błędnych.

Przykładowo, proces, którego funkcją jest drukowanie faktur można opisać po-przez specyfikację:

Proces 1. Wydruk faktury WARUNEK POCZĄTKOWY 1 Istnieje faktura w magazynie Faktury Której Nr_faktury pasuje

Do Nr_faktury w magazynie Usługi na fakturze

WARUNEK KOŃCOWY 1

Drukowanie zestawienia dla Nr_faktury zawierajacego:

Nr_faktury + PESEL_klienta + Nazwisko + Imię + Kod + Miejscowość + Ulica + Data_wystawienia + Opis_usługi + Cena

WARUNEK POCZĄTKOWY 2

Istnieje faktura z Nr_faktury nie pasującym

Do Nr_faktury w magazynie FAKTURY

WARUNEK KOŃCOWY 2

Generowanie komunikatu: „Nie istnieje faktura o numerze Nr_faktury”

Jeszcze innym sposobem umożliwiającym specyfikację procesów jest budowanie

tablic decyzyjnych. Metoda ta jest najczęściej przydatna w sytuacjach, gdy decyzje, od

zmien-nych mogących przyjmować różne wartości. Tablica decyzyjna zbudowana jest z ko-lumny zawierającej wszystkie zmienne wejściowe oraz wszystkie akcje, które może podjąć proces. W następnych kolumnach tabeli umieszczane są wszystkie możliwe kombinacje wartości zmiennych wraz z towarzyszącymi im akcjami – są to tzw. regu-ły. Dla N zmiennych o wartościach binarnych otrzymuje się więc 2N reguł. Tablica decyzyjna opisująca proces udzielania rabatu klientom w zależności od ilości zaku-pionego towaru, wartości transakcji oraz statusu klienta (klient stały lub okazjonalny) może mieć na przykład postać jak na rys. 6.21.

1 2 3 4 5 6 7 8 Status klienta S S O O S S O O Ilość > 1000 szt. T T T T N N N N Wartość > 1500 T N T N T N T N Rabat 1 X X Rabat 2 X X Rabat 3 X X Bez rabatu X X

Rys. 6.21. Tablica decyzyjna jako specyfikacja procesu

W praktyce warunki (zmienne wejściowe) nie zawsze są typu binarnego, co wpły-wa na rozmiar tablicy decyzyjnej (aby określić liczbę reguł, należy pomnożyć przez siebie liczby możliwych wartości kolejnych zmiennych; przykładowo, jeśli zmienna 1 przyjmuje dwie wartości, zmienna 2 trzy wartości, zmienna 3 cztery wartości, to w tablicy decyzyjnej muszą pojawić się 24 reguły).

Specyfikacje procesów, niezależnie od wybranej metody ich opracowania, są jedną z bardziej pracochłonnych czynności w cyklu budowania modelu systemu. Będąc składową modelu, jednocześnie stanowią test poprawności dla diagramów przepływu danych. Często okazuje się (w trakcie opracowywania specyfikacji), że diagram DFD powinien zostać rozbudowany o dodatkowe przepływy danych, lub że niektóre proce-sy powinny zostać zdekomponowane, gdyż realizują kilka rozłącznych funkcji. W trakcie pisania specyfikacji najczęściej ujawniają się braki procesów modyfikują-cych lub usuwająmodyfikują-cych dane z magazynów.

Na tym etapie można przyjąć, że model systemu (inaczej mówiąc, model reguł przetwarzania) w odniesieniu do systemów bazodanowych jest kompletny i udoku-mentowany. Należy pamiętać, że w procesie kreowania modelu za pomocą narzędzi CASE większa część dokumentacji przechowywana jest w repozytorium pakietów – w przypadku programu ProcessAnalyst w plikach z rozszerzeniem *.PAM, co pozwala na wykorzystanie zdefiniowanych obiektów i struktur w następnych etapach projek-towania. Polecenie zachowania modelu wykonywane jest poprzez wybór menu File → Save lub File → Save As.

Następnym krokiem jest opracowanie modelu danych, czyli układu danych (struk-tury i powiązania), przechowywanych w systemie.

7

Modelowanie danych,