Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona33/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   29   30   31   32   33   34   35   36   ...   113

Diagramy Stanów (State diagram)


Diagram stanów (state diagram, state-machine diagram, statechart diagram) to jest diagram, w którym węzłami są stany jakiegoś procesu ( w sensie czynności, które są wykonywane przez ten proces), zaś krawędzie oznaczają przepływ sterowania (przejścia) pomiędzy tymi stanami. Diagram stanu jest przeznaczony dla modelowania zachowania obiektów tylko jednej klasy! To znaczy, że wszystkie stany na tym diagramu są stanami obiektów tylko tej samej klasy. W przeciwieństwie do diagramów stanów diagramy przebiegu mogą modelować zachowanie obiektów różnych klas.

W metodykach analizy i projektowania systemów informatycznych diagramy stanów mogą występować na różnych poziomach abstrakcji, gdzie poziom bardziej szczegółowy jest rozwinięciem poziomu bardziej abstrakcyjnego.

Diagram stanów to jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu: przypadków użycia, przebiegu, kooperacji, czynności i stanów. Diagramy stanów mogą być stworzone dla następnych elementów UML:


  • Klas (konceptualnych oraz programowych),

  • Przypadków użycia.

Cały system informatyczny może być przedstawiony w postaci klasy, dlatego diagram stanów może być wykorzystywany dla modelowania całego systemu lub go części. Diagram stanów to jest maszyna stanowa, która pokazuje kolejność stanów modelowanego obiektu. W odróżnieniu od diagramów czynności (którą będziemy rozpatrywać później), diagramy stanów służą do modelowania zachowania obiektów reaktywnych, to znaczy obiektów, których działania są najlepiej określane przez ciąg odpowiedzi na zdarzenia wywołane w otoczeniu tych obiektów (ich kontekstu). Zwykle taki obiekt jest bezczynny do chwili zajścia zdarzenia. Gdy ono nastąpi, jego reakcja najczęściej zależy od wcześniejszych zdarzeń. Po zakończeniu akcji spowodowanych zdarzeniem obiekt znów jest bezczynny i czeka na następne zdarzenia. W wypadku tego rodzaju obiektów należy kłaść nacisk na stany stabilne, oraz na zdarzenia uruchamiające przejścia i akcje wykonywane przy każdej zmianie stanu.

W przeciwieństwie do diagramów stanu, Diagramy czynności (aktywności) służą dla odwzorowania procesów biznesowych, to znaczy do modelowania przepływu czynności lub operacji procesu przetwarzania informacji. Diagram czynności pokazuje nie stany obiektów, lecz etapy realizowanych obliczeń lub czynności procesu biznesowego, zakładając przy tym, że zdarzenia (zewnętrzne oraz wewnętrzne) w ciągu tego procesu są nieobecne. Diagramy czynności lepiej nadają się do definiowania kolejno wykonywanych czynności, tak jak robi się to na schemacie blokowym algorytmu.

Wadą diagramów stanu oraz czynności jest to, że te diagramy nie wpływają na ostateczny kod wygenerowany przez PowerDesigner (lub inne CASE narzędzie). Jednak to nie oznaczy, że te diagramy są zbyteczne. Diagram stanu jest modelem obiektu klasy programowej lub przypadku użycia . Ten model jest realizowany za dopomogą pojęć i formalizmów teorii maszyn stanowych. To pozwoli przedstawić zachowanie obiektu w postaci oddzielnych stanów oraz przejść pomiędzy nimi. Zgodnie z teorią maszyn stanowych jakakolwiek złożona maszyna stanowa może być podzielona na zwykle maszyny stanowe. Dekompozycja zachowania klas po stanach pozwoli wyznaczyć i definiować metody i atrybuty tych klas.

Zgodnie ze standardem UML diagram stanów odwzorowuje następne czynności:



  • Zbiór stanów modelowanej klasy lub przypadku użycia

  • Zdarzenia które inicjują przejścia pomiędzy oddzielnymi stanami oraz w samych stanach

  • Akcji, które są realizowane w stanach

  • Akcji, które są realizowane w przejściach.

Na rys. 93 jest pokazany diagram stanów obiektów klasy „Authentification”. Obiekty tej klasy są przeznaczone dla walidacji użytkownika systemu informacyjnego. Rezultatem analizy zachowania obiektów tej klasy są następne stany:

  • Editing - początkowy stan obiektu

  • Validating – stan walidacji danych wpisanych przez użytkownika

  • Validatedużytkownik ma prawa dostępu

  • Refused - użytkownik nie ma prawa dostępu

  • Canceled – użytkownik przekroczył czas na walidację.

Początkowym stanem obiektu jest stan „Editing” w którym Użytkownik edytuje swój identyfikator oraz hasło. Z tego stanu jest możliwe przejście do stanu „Validating” lub do stanu „Canceled”. Do stanu „Canceled” przejście będzie realizowane po przekroczeniu czasu wyłącznika zegarowego. Do stanu „Validating” przejście będzie realizowane po kliknięciu przyciska „SUBMIT”. W stanie „Validating” realizują się polecenia do bazy danych z danymi użytkownika. W przypadku istnienia odpowiednich uprawnień obiekt przechodzi do stanu „Validated”, w innym przypadku – do stanu „Refused”.

Rys. 93


Przejścia pomiędzy stanami na diagramu są pokazane przez strzałki . Każda strzałka odpowiada wyznaczonemu zdarzeniu, które powoduje przejście do następnego stanu.

Stan obiektu to jest okoliczność lub sytuacja, w jakiej się obiekt znajduje w czasie swego życia, kiedy spełnia jakiś warunek, wykonuje jakąś czynność lub czeka na jakieś zdarzenie.

Stan obiektu ma następne atrybuty i składniki:



  • Namenazwa stanu

  • Classifier – klasa obiektu

  • Composite – obecność podstanów (stanów włożonych)

  • Actions – akcje wykonywane – odpowiednio – przy wejściu do stanu, w stanie i przy wyjściu z niego

  • Deferred events – zdarzenia odroczone – to jest lista zdarzeń, które są generowane przez system, ale nie są obsługiwane w tym stanie. Te zdarzenia są odraczane i umieszczane w kolejce, po czym są obsługiwane w innym stanie.

  • Dependencies zależności , są to związki z innymi stanami.

Wszystkie atrybuty i składniki stanów mogą być wyznaczone w oknie „State Properties” PowerDesignera.

Wszystkie zdarzenia mogą być następnych typów:



  • Zdarzenia zewnętrzne( lub zdarzenia systemowe). Te zdarzenia są inicjowane przez zewnętrzne warunki, np. naciśnięcie przycisku „wprowadź” dla przesyłania danych formularza pro identyfikator ta hasło użytkownika. Zdarzenia zewnętrzne najczęściej są odwzorowane na diagramach przebiegu.

  • Zdarzenia wewnętrzne. Te zdarzenia są inicjowane przez wewnętrzne warunki, np. odpowiedź serwera pro nieobecność uprawnień Użytkownika („denial”).

Wszystkie zdarzenia w modelu mogą być wyznaczone w PowerDesigner za dopomogą opcji menu MODEL>EVENTS oraz mogą być definiowane jako trygery w przejściach. Na rys.94 jest pokazana tabela dla definiowania zdarzeń w modelu oraz lista tych zdarzeń.

Rys.94


Na rys.95 jest pokazany katalog obiektów „Events” w przeglądarce PowerDesignera. Zdarzenie „Submit” zawiera parametry.

Rys.95


Każdy stan diagramy stanów może być skojarzony z odpowiednią klasą. Na rys.96 jest pokazane okno „State Properties” oraz pole „Classifier” gdzie może być wyznaczona klasa dla tego stanu.

Rys.96


Diagram stanów skojarzony z klasą wyznaczy sposób reakcji obiektów klasy na wszystkie zdarzenia. To znaczy, że diagram dokładnie definiuje dla każdego stanu obiektu odpowiednią akcję, która musi być zrealizowana przy zdarzeniu. Ten samy obiekt może realizować różne akcji na wyznaczone zdarzenie w zależności od stanu obiektu. Realizacja akcji może spowodować zmianę stanu obiektu. Opis przejścia na diagramu stanów w tym przypadku musi zawierać opis zdarzenia i akcję. Pełny opis przejścia (transition) na obrazku diagramu ma następny format:

Trigger_Event ( parameters) [condition] / action

Każdy z składników tego formatu jest opcjonalny. To znaczy, że w przypadkach kiedy przejście jest oczywiste (przejście bez zdarzenia) w ogóle może nie być opisu. Wszystkie komponenty opisu przejścia mogą być zadane w oknie „Properties transition” na diagramu stanów. Niżej jest podany opis głównych właściwości i atrybuty przejścia:



1   ...   29   30   31   32   33   34   35   36   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna