Projektowanie systemów informacyjnych

Projektowanie systemów informacyjnych Wykład 7: OMT - Modele dynamiczne. Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

OMT - modelowanie dynamiczne • Zdarzenia i stany • Scenariusze • Trop zdarzeń • Diagram stanów, operacje • Współbieżność • Zalecenia praktyczne

Modele dynamiczne Modele, które uwzględniają: czas, zdarzenia, następstwo czynności, synchronizację czynności, transakcje, stany procesów, spontaniczne akcje, interakcję z otoczeniem systemu, dialogi. Zwykle są notacjami opartymi na diagramach przepływu sterowania, diagramach automatów skończonych, sieciach Petri’ego, sieciach PERT, ....... Model dynamiczny jest zwykle związany z modelem funkcjonalnym i modelem danych wspólnymi oznaczeniami (obiektów, procesów).

Stany states Stan obiektu Zestaw wszystkich wartości atrybutów tego obiektu oraz jego aktualnych powiązań z innymi obiektami w danej chwili czasowej. Stan obiektu trwa w czasie aż do momentu zajścia zdarzenia lub operacji, które zmienia stan na inny. Np. stanem obiektu OSOBA jest zestaw wartości (NAZWISKO: Kowalski, IMIĘ: Adam, ZATRUDNIONY_W: Firma 132435) Ile obiekt może mieć stanów? Bardzo dużo. Jeżeli np. może być 1 000 000 nazwisk, 1 000 imion i 100 000 firm, to liczba stanów wynosi 100 000 000 000 000. Normalnie, nawet dla niedużego obiektu liczba stanów jest nie do przeliczenia. Bardzo, bardzo dużo: iloczyn wszystkich ilości stanów dla wszystkich obiektów i powiązań. Ile stanów ma cała baza danych? Niemniej pojęcie stanu jest bardzo istotne, gdyż jest to “zdjęcie migawkowe” jednej sytuacji w której znalazł się nasz system informacyjny. Często abstrahuje się od pewnych składników stanu, lub “zlepia się” wiele stanów w jeden. Przy analizie i projektowaniu najbardziej istotne są stany związane z: - sterowaniem pewną akcją: stan oznacza w fazę przetwarzania - statusem pewnych obiektów: np. dokument może być przygotowywany, napisany, zatwierdzony, zarchiwizowany, zniszczony

Zdarzenia events Zdarzeniem jest coś, co następuje w jednym punkcie czasowym (z punktu widzenia naszej percepcji czasu) i warte jest analizowania z punktu widzenia celów projektowanego systemu informacyjnego. Samo zdarzenie nie trwa w czasie, ale fakt zaistnienia zdarzenia jest zarejestrowany i trwa aż do momentu, gdy jakiś podmiot go “skonsumuje”. Np. zdarzeniem jest naciśnięcie przez użytkownika lewego klawisza myszy, lub odlot samolotu w dniu 20 stycznia 1997 o godz. 19:00 z Warszawy do Paryża. Zdarzenia mogą być uporządkowane w czasie, ale możemy także rozpatrywać zdarzenia jak współbieżne. Zdarzenia mogą być grupowane w klasy i mogą im być przypisane atrybuty. Zdarzenia warto rozpatrywać w okreslonym kontekście, np. czym innym będzie naciśnięcie klucza Esc jeżeli użytkownik ogląda Pomoc, a czym innym będzie w głównym menu. Zwykle wystąpienie zdarzenia wywołuje pewną przyporzadkowaną mu akcję systemu, która najcześciej zmienia stan (obiektu lub sterowania).

Przykłady klas zdarzeń • samolot odlatuje( linia lotnicza, nr lotu, miasto ) • naciśnięty klawisz myszy ( klawisz, lokacja kursora ) • wprowadzono ciąg znaków ( tekst ) • podniesiono słuchawkę telefonu • wybrano cyfrę numeru telefonu (cyfra) • obroty silnika wkroczyły w niebezpieczną strefę Zdarzenia włączają błedy jako szczególny przypadek. Np. silnik się zatarł, transakcja została zerwana, czas upłynął są normalnymi wystąpieniami zdarzeń.

Scenariusze scenario Scenariusz jest sekwencją zdarzeń, które występują podczas przebiegu systemu. Scenariusz może abstrahować od zdarzeń, które są nieistotne lub drugorzędne dla tego przebiegu. Dzwoniący podnosi słuchawkę Uruchomienie tonu w słuchawce Dzwoniący wybiera cyfrę(5) Ton w słuchawce znika Dzwoniący wybiera cyfrę(6) Dzwoniący wybiera cyfrę(4) Dzwoniący wybiera cyfrę(9) Dzwonek w telefonie odbiorcy Ton dzwonka u dzwoniącego Odbiorca podnosi słuchawkę Telefon odbiorcy przestaje dzwonić Ton dzwonka u dzwoniącego znika Telefony są połączone Odbiorca kładzie słuchawkę Telefony są rozłączone Dzwoniący kładzie słuchawkę Np. scenariusz dla rozmowy telefonicznej:

Trop zdarzeń event trace Sekwencję zdarzeń oraz zdarzeń występujących między obiektami można pokazać w rozszerzonym diagramie zwanym tropem zdarzeń. Linia telefoniczna Dzwoniący Odbiorca Dzwoniący podnosi słuchawkę Uruchomienie tonu w słuchawce Dzwoniący wybiera cyfrę(5) Ton w słuchawce znika Dzwoniący wybiera cyfrę(6) Dzwoniący wybiera cyfrę(4) Dzwoniący wybiera cyfrę(9) Ton dzwonka u dzwoniącego Ton dzwonka u dzwoniącego znika Telefony są połączone Telefony są rozłączone Dzwoniący kładzie słuchawkę Dzwonek w telefonie odbiorcy Odbiorca podnosi słuchawkę Telefon odbiorcy przestaje dzwonić Telefony są połączone Odbiorca kładzie słuchawkę Telefony są rozłączone

Inny przykład tropu zdarzeń Czerwony Kapturek Domek babci Wilk Babcia Leśniczy Opuszcza dom Spotyka Przychodzi do Połyka Spotyka Przychodzi do Pyta Odpowiada Połyka Przychodzi Rozpoznaje Rozpruwa Uwalnia Uwalnia

Diagram stanów Przekazanie komunikatu Wybieranie o błędnym numeru numerze prawidłowy numer Sygnał koniec zajętości komunikatu podniesienie słuchawki przez odbiorcę położenie słuchawki przez odbiorcę położenie słuchawki położenie słuchawki Stan spoczynku podniesienie słuchawki czas się skończył Koniec limitu Sygnał ciągły czasu cyfra(n) czas się skończył cyfra(n) błędny numer Przejścia na diagramie stanów mogą być warunkowe. Warunek umieszcza się w nawiasach za odpowiednim zdarzeniem. Łączenie linia zajęta Dzwonek Połączenie Uwaga terminologiczna: wprowadzony “diagram stanów” jest w istocie raczej diagramem przepływu sterowania (flowchart). Pojęcie “stanu” zwykle włącza więcej elementów niż tylko sterowanie. Rozłączenie

Operacje Przekazanie komunikatu Wybieranie o błędnym numeru numerze do: odegraj komunikat prawidłowy numer koniec Sygnał komunikatu zajętości podniesienie słuchawki przez odbiorcę/łącz linie położenie słuchawki przez odbiorcę/rozłącz linie położ_sł położ_sł Stan spoczynku podniesienie słuchawki czas się skończył położ_sł Koniec limitu Sygnał ciągły czasu cyfra(n) czas się skończył cyfra(n) położ_sł błędny numer położ_sł Łączenie linia zajęta położ_sł Zdarzenia mogą wyzwalać operacje. Nazwę operacji umieszcza się za zdarzeniem i warunkim, poprzedzając ją znakiem /, lub po znakach do: wewnątrz stanów. Dzwonek położ_sł/rozłącz linie Połączenie położ_sł Rozłączenie

Przykład: model automatu sprzedającego wrzucona moneta(wartość) / zainicjuj bilans Zliczanie pieniędzy wrzucone monety(wartość) /dodaj do bilansu Stan spoczynku kasowanie / zwróć monety [brak pozycji] wybór(pozycja) [reszta < 0] [reszta = 0] do: sprawdź wybraną pozycję i oblicz resztę do: wydaj pozycję do: wydaj resztę [reszta > 0] ramię gotowe ramię gotowe wypchnięta do: przesuń ramię do właściwego wiersza do: przesuń ramię do właściwej kolumny do: wypchnij pozycję

Generalizacja zdarzeń Zdarzenia mogą być traktowane jak obiekty, ewentualnie z atrybutami. zdarzenie czas Zdarzenia związane z akcjami użytkownika: info_wejściowe urządzenie naciśnięcie_klawisza_klawiatury kod_znaku klik_klawisza_myszy lokalizacja naciśnięcie_klawisza_myszy sterujący znakowy puszczenie_klawisza_myszy spacja alfanumeryczny interpunkcyjny

Wewnętrzne akcje Zdarzenie może powodować akcję, która nie powoduje zmiany stanu. Taką akcję umieszcza się za nazwą zdarzenia i znakiem /. Podsumowanie notacji: Stan2 ..... Stan1 do: aktywność1 entry / akcja2 exit / akcja3 zdarzenie / akcja4 zdarzenie1(atryb1) [warunek1] / akcja1 zdarzenie2(atryb2) } do entry exit słowa zastrzeżone Klasa obiektów

Współbieżność concurrency Model dynamiczny opisuje zbiór obiektów, które działają współbieżnie; każdy z nich posiada własny stan i diagram stanów. Samochód Hamulec hamulec naciśnięty Zapłon Biegi Hamulce Gaz Włącz Wył hamulec puszczony Zapłon kluczyk do max w prawo [Biegi w pozycji 0] Wył Zapala Włącz kluczyk do poz wył Uwaga: podejście OMT do kwestii współbieżności jest nieco naiwne - słabo uwzględnia synchronizację i dostęp do dzielonych zasobów. Biegi .... Gaz ....

Synchronizacja współbieżnych akcji Obiekt może wykonywać współbieżnie dowolną liczbę akcji. Automat do wypłacania pieniędzy Wypłata gotówka wydana do: wydaj gotówkę gotowy Włączenie automatu Gotowy do działania AND do: oddaj kartę karta oddana Synchronizacja: wszystkie współbieżne procesy muszą się zakończyć aby kontynuować Podział na współbieżne procesy

Diagramy zagnieżdżone Diagramy stanów mogą być rozrysowane na różnych poziomach abstrakcji. Czynność przedstawiona na diagramie może być dalej bardziej szczegółowo rozpisana na pod-diagramie. Zakup Przygotowanie wniosku Akceptacja kierownika Informacja o odrzuceniu Akceptacja prezesa Akceptacja księgowości Dokonanie zakupu Zakup

Przykład wymagań dla diagramu stanów: Zakupy dla firmy • Pracownik firmy zgłasza wniosek o zakup (np. paczki pinesek) do kierownika zaopatrzenia. • Kierownik uruchamia procedurę zakupu i wyznacza odpowiedzialnego za to swojego pracownika. • Ten pracownik przygotowuje informację o zakupie (ceny, jakość, dostawcy) i swój wybór. • Kierownik przegląda informację i zatwierdza wniosek lub nie. • Jeżeli zatwierdza, to dalsze postępowanie zależy od szacunkowego kosztu zakupu. • Jeżeli koszt jest poniżej 1000 ECU, to wniosek musi zaakceptować dział finansowy. • Pracownik zaopatrzenia przekazuje wniosek do działu finasowego. • Dział finansowy może wniosek zaakceptować, odrzucić lub mieć wątpliwości i skierować do prezesa. • Wniosek dla prezesa przekazuje pracownik zaopatrzenia odpowiedzialny za zakup. • Jeżeli zakup jest powyżej 1000 ECU, to akceptacji musi dokonać prezes. • Prezes może wniosek zaakceptować lub odrzucić. • Po akceptacji prezesa wniosek musi jeszcze przejść procedurę w dziale finansowym, j.w. • Jeżeli wniosek jest odrzucony w dowolnej fazie, to pracownik zaopatrzenia musi o tym pisemnie poinformować wnioskodawcę • Jeżeli wniosek jest zakceptowany, to pracownik zaopatrzenia musi równocześnie pisemnie poinformować wnioskodawcę i dokonać zakupu.

Przykład: diagram stanów utwórz [zaakceptowany] [koszt >= 1000ECU] [koszt < 1000ECU] utwórz [zaakceptowany] Zakupy dla firmy Startuj wystąpienie procesu Przygotuj info o zakupie Wniosek Pracownik Kierownik dekretuj_na Info o zakupie Info o odrzuceniu Formularz wniosku utwórz Akceptacja Przygotuj info o odrzuceniu [odrzucony] Kierownik Pracownik [odrzucony] [odrzucony] Przygotuj info o akceptacji Akceptacja (przez prezesa) Rejestruj akcept. prezesa Pracownik Pracownik Info o akceptacji [zaakceptowany] [wątpliwości] Akceptacja (przez dział finansowy) Rejestruj akcept. dzialu finansowego Zakup AND Pracownik

Przykład: diagram tropów komunikatów Zakupy dla firmy Kierownik Dokumentacja Budżet zakupu Formularz wniosku Info o zakupie Katalogi produktów sprawdź budżet info o budżecie daj dane o zakupie daj info o wniosku info o wniosku daj info o zakupie daj info katalogowe info katalogowe info o zakupie dane o zakupie decyzja akceptacyjna

Zalecenia praktyczne (1) • Konstruuj diagram stanów tylko dla obiektów z istotnym dynamicznym • zachowaniem. Nie wszystkie obiekty wymagają modelu stanów. • Sprawdzaj różne diagramy stanów na spójność wspólnych zdarzeń, tak aby • pełny model dynamiczny był poprawny. • Używaj scenariuszy dla wspomożenia początku konstruowania diagramu stanów. • Definiując stan rozpatruj tylko relewantne atrybuty. Nie wszystkie atrybuty • muszą być użyte w diagramie stanów. • Dla danej aplikacji rozważ odpowiednią granulowośczdarzeń i stanów. • Rozróżniaj pomiędzy aktywnościami i akcjami. Aktywności trwają dłuższy czas, • natomiast akcje są chwilowe w rozważanej skali czasowej.

Zalecenia praktyczne (2) • Kiedy stan ma wiele wchodzących strza łek i wszystkie są opatrzone tą samą akcją, • zamiast powtarzać ją przy wszystkich strzałkach włóż tę akcję wewnątrz oznaczenia • stanu poprzedzając ją zdarzeniem entry. Podobnie rób dla zdarzeń wychodzących. • Jeżeli ta sama transakcja ma zastosowanie do wielu stanów użyj zagnieżdżonego • diagramu stanów. • W większości współbieżność wynika z agregacji obiektu i nie musi być wyrażana • explicite w diagramie stanów. Użyj składanego stanu dla pokazania niezależnych • czynników zachowania się pojedyńczego obiektu. • Staraj się uczynić diagram stanu odnoszący się do podklasy niezależny od • diagramów stanów dla jej superklas. Diagram stanów podklasy powinien • koncentrować się prawie wyłącznie na jej atrybutach. • Uważaj na niepożądane gonitwy warunków. Mogą one powstać wtedy, gdy dany • stan może zaakceptować zdarzenia pochodzące z więcej niż jednego obiektu.

Podsumowanie terminologii modelu dynamicznego (1) AkcjaPojedyncza operacja. Akcje są zazwyczaj powodowane przez zdarzenia, mogą powodować zdarzenia i mają swój formalny opis. Aktywność Operacja, której wykonanie wymaga pewnego czasu. Aktywności są związane ze zmianą stanu. Diagram stanów Graf zorientowany, którego węzły oznaczają stany, zaś łuki oznaczają przejścia pomiędzy stanami. Diagram stanów może pomijać (abstrahować) od pewnych składników stanu. Zagnieżdżony diagram stanów Diagram stanów, którego węzły są rozwinięte jako pod-diagramy. Model dynamiczny Opis tych aspektów systemu, które dotyczą sterowania, włączając w to czas, następstwo operacji, zdarzenia i interakcje obiektów. Operacja Funkcja lub transformacja, która może być zastosowana do obiektu.

Podsumowanie terminologii modelu dynamicznego (2) Przejście Zmiana stanu spowodowana przez zdarzenie Scenariusz Sekwencja zdarzeń powodowana przez pewien konkretny przebieg systemu. Stan Wartości atrybutów i powiązań obiektu w pewnym momencie czasowym. Sterowanie Aspekt systemu opisujący sekwencję kolejnych operacji. Trop zdarzeń Diagram pokazujący obiekty wysyłające i odbierające zdarzenia oraz sekwencję zdarzeń. Warunek Funkcja Boolowska, zwykle na wartościach atrybutów, od której może zależeć przejście pomiędzy stanami Współbieżność Możliwość niezależnego, równoległego przebiegu pewnych zadań, aktywności; niezależne pojawianie się zdarzeń i niezalezna reakcja na zdarzenia. Zdarzenie Zarejestrowany fakt pojawiający się w pewnym punkcie czasowym.

Projektowanie systemów informacyjnych