Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona25/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   21   22   23   24   25   26   27   28   ...   113

Liczba stereotypów może być rozszerzana. Mechanizm ten ułatwia dostosowanie języka UML do nowych technologii.


Dokumentowanie oraz konstruowanie przypadków użycia


Celem diagramów przypadków użycia jest dokumentowanie oddzielnych przypadków, aktorów i związków między nimi. Dla dokumentowania mogą być wykorzystywane następne zakładki okna właściwości (Properties) przypadku użycia:

  1. Action Steps – opis scenariusza głównego oraz alternatywnego

  2. Extension Points – opis warunków, aktywacji źródłowego scenariusza, który rozszerza za dopomogą związku docelowy scenariusz. (IF THEN)

  3. Exceptions – Opis reakcji na zdarzenia przy realizacji tego przypadku użycia.

  4. Pre-Conditions – Warunki początkowe, które muszą być spełnione dla rozpoczęcia przypadku użycia. N.p. obecność wyznaczonej informacji w bazie danych lub poprzednia realizacja innego przypadku użycia.

  5. Post-Conditions - Warunki końcowe, które muszą być spełnione po realizacji tego przypadku użycia. N.p. stworzenie obiektu zakupu. W tej części dokumentacji mogą być wyznaczone przypadki użycia, które muszą być uruchomiane po realizacji tego przypadku użycia.

Dla opracowania przypadków użycia trzeba wykorzystywać następne rekomendacje:

  • Nie należy modelować związki asocjacji pomiędzy aktorami. Aktorzy są kontekstem systemu, to znaczy przypływ informacji pomiędzy aktorami realizuje się na zewnętrz systemu. Pomiędzy aktorami mogą być tylko związki dziedziczenia.

  • Pomiędzy oddzielnymi przypadkami użycia w dużej ilości wypadków mogą być związki tylko dwóch typów: <> oraz <>. Związki na diagramie przypadków użycia wyznaczają tylko jakie przypadki użycia mogą dostępne w systemie. Związki nie definiują kolejność realizacji tych przypadków użycia! Dla odwzorowania kolejności realizacji oddzielnych przypadków użycia wykorzystują się diagramy przebiegu. Kolejny przypadek użycia może być wyznaczony także w zakładce „Post-Conditions”.

  • Każdy przypadek użycia musi być inicjowany przez aktora. To oznaczy, że dla każdego przypadku użycia musi być wyznaczona strzałka komunikacji od aktora do tego przypadku użycia ( Wyjątkiem są związki <> oraz <> ). Strzałka komunikacji w ten sposób wyznaczy się inicjatora komunikacji. Inicjatorem może występować aktor, oraz w tym wypadku strzałka jest skierowana od aktora do przypadku użycia. Kiedy inicjatorem występuje system, strzałka komunikacji jest skierowana od przypadku użycia do aktora. Strzałka komunikacji nie definiuje kierunek przepływu informacji pomiędzy aktorem i przypadkiem użycia, informacja może przepływać w dwóch kierunkach, strzałka wyznaczy tylko inicjatora komunikacji!

  • Baza danych może być warstwą umowną pod diagramem przypadków użycia. Jeden przypadek użycia może wprowadzać dani do bazy danych, inny przypadek użycia może odczytywać te dani.

Diagramy interakcji (Interaction diagram)


Diagram interakcji to jest diagram ułatwiający zrozumienie zależności w przepływie sterowania. Metody realizujące to sterowanie są rozproszone w wielu klasach modelu, co powoduje trudności ze zrozumieniem ich wzajemnej zależności i interakcji. Diagramy interakcji służą do opisu zależności przy przesyłaniu komunikatów dla pewnej grupy obiektów, do modelowania dynamicznych aspektów systemu. Uwzględnia się na nich konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty przekazywane między nimi. Te wszystkie byty są rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie systemu. Diagramy interakcji mogą występować samodzielnie; wtedy służą do obrazowania, specyfikowania, tworzenia i dokumentowania dynamicznych aspektów ustalonego zestawu obiektów. Mogą także być użyte do modelowania jednego specyficznego przepływu sterowania w przypadku użycia.

Diagram interakcji to wspólna nazwa dla diagramu przebiegu i diagramu kooperacji. Każdy diagram przebiegu i każdy diagram kooperacji są jednocześnie diagramami interakcji, a każdy diagram interakcji jest albo diagramem przebiegu, albo diagramem kooperacji. Diagramy przebiegu i diagramy kooperacji są izomorficzne, to znaczy można swobodnie przekształcać jeden w drugi, bez groźby utraty informacji.


Diagram przebiegu(Sequence diagram)


Diagram przebiegu (Diagram sekwencji) to jest diagram interakcji, na którym kładzie się nacisk na kolejność komunikatów w czasie. Przedstawia się na nim zbiór obiektów i komunikaty, jakie obiekty wysyłają i odbierają. Obiekty to zwykle nazwane lub anonimowe egzemplarze klas, choć mogą, także reprezentować egzemplarze innych elementów, takich jak kooperacje, komponenty i węzły.

Komunikat to specyfikacja środka łączności między obiektami, przenoszącego zlecenia wykonania określonych czynności. Otrzymanie egzemplarza komunikatu można uważać za egzemplarz zdarzenia.

Akcja spowodowana przekazaniem komunikatu może spowodować realizacje procedury obliczeniowej. Akcja może prowadzić do zmiany stanu obiektu. W UML wyróżnia się następne rodzaje komunikatów (control flow) (rys. 64):



Rys.64


Asynchronous – obiekt nadawca komunikatu nie będzie oczekiwał rezultatu od obiektu odbiorcy. Obiekt nadawca może stworzyć inne paralelne komunikaty. Ten typ komunikatu jest analogiem skrzyni pocztowej.

Procedure Call – dochodzi do wywołania operacji oraz innych włożonych komunikatów na obiekcie odbiorcy. Obiekt nadawca nie może wysłać kolejny komunikat dopóki nie otrzyma odpowiedz pro zakończenie aktywacji od obiektu odbiorcy. Obiekt może wysyłać komunikat do samego siebie; oznacza to lokalne wywołanie operacji. Ten typ komunikatu jest synchronicznym.

Return– dochodzi do przekazania wartości wywołującemu. Zazwyczaj ten typ komunikatu jest skojarzony z „Procedure Call”.

Undefined – to jest domyślny typ komunikatu. Oznaczy się płaski (неструктурированный) przepływ sterowania (ciągi płaskie). W ten sposób jest odwzorowany nieproceduralny przepływ sterowania.

Ustalić typ komunikatu można w oknie „Properties” komunikatu, w zakładce „Detail”, w polu „Control flow” (rys. 65).


Rys. 65


Różnica między ciągami płaskim a proceduralnym polega na tym, że ciągi płaskie stosują się do modelowania interakcji związanych z przypadkami użycia, obejmującymi system jako całość, wraz z aktorami z jego otoczenia. W takich przebiegach sterowanie przepływa między kolejnymi krokami, bez względu na zagnieżdżenia. We wszystkich pozostałych wypadkach korzysta się z ciągów proceduralnych, gdyż reprezentują one zwykłe zagnieżdżone wywołania operacji, jakie występują w większości języków programowania.

W UML mogą być realizowane następne typy akcji, który są związane z komunikatami:



Create – Dochodzi do utworzenia nowego obiektu.

Destroy – Dochodzi do zniszczenia obiektu. Może on też popełnić samobójstwo, niszcząc sam siebie. Ustalić typ akcji komunikatu w oknie „Properties” komunikatu, w zakładce „Detail”, w polu „Action” (rys.66).

Rys.66


Na diagramie przebiegu uwypukla się kolejność komunikatów w czasie. Jest diagramem interakcji obrazującym interakcję jako zbiór obiektów i związków między nimi oraz komunikaty, jakie obiekty przekazują między sobą. Diagram ma postać tabeli, w której obiekty są ułożone wzdłuż osi X, a komunikaty wzdłuż osi Y, uporządkowane według czasu ich wysłania. Taki sposób obrazowania ułatwia czytelnikowi diagramu zrozumienie przepływu sterowania w czasie. Przykład diagramu przebiegu jest pokazany

na rys.67



.

rys. 67


Caller – abonent dzwoniący

Exchange – centrala telefoniczna

Receiver – abonent odbierający

Lift receiver – podnieść słuchawkę



Dial tone - ton w słuchawce (zezwolenie wprowadzenia numeru)

Dial digit - wybieranie cyfry

Ringing tone - ton dzwonka

Phone rings –uruchomienie dzwonka

Answer phone - podniesienie słuchawki

Stop tone - koniec tonu

Stop rinding – koniec dzwonienia

Przykład diagramu przebiegu automatu wypłaty gotówki jest pokazany na rys. 67a.



Rys. 67a


Diagramy przebiegu maja dwie cechy, które odróżniają je od diagramów kooperacji.



1   ...   21   22   23   24   25   26   27   28   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna