Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona29/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   25   26   27   28   29   30   31   32   ...   113

Stworzenie diagramu przebiegu (Sequence Diagram)


Zachowanie (funkcjonalność) każdego elementu Use Case może być odwzorowane w sposób graficzny w oddzielnym diagramu przebiegu. Ten diagram odwzorowuje jeden z możliwych scenariuszy plonu zdarzeń elementu Use Case, np., dodawanie studenta do kursu. Diagramy przebiegu zawierają obiekty oraz komunikaty pomiędzy nimi, które realizują zachowanie elementu Use Case. Rozpatrzymy stworzenie diagramu realizującego rejestrację studenta.

Stworzymy nowy diagram przebiegu w środowisku PowerDesigner. Przeniesiemy aktora „Student” z panelu przeglądarki projektu do diagramu przebiegu. W scenariuszu rejestracji student musi uzupełnić formularz ze swoimi danymi, potem odesłać ten formularz do systemu. Dla realizacji tej części scenariusza potrzebny jest obiekt „Registration Form” , który otrzymuje informację od studenta. Celem tego obiektu jest wizualizacja formularza na komputerze użytkownika oraz przesyłanie danych do innych obiektów. Stworzymy ten obiekt oraz komunikaty „Uzupełnić formularz” (fill in information) i „Submit” (rys.72 ).



Rys.72

Oczywiście obiekt „Registration Form” nie jest obiektem ostatnim w ciągu obiektów przepływu informacji. Kolejnym obiektem musi być obiekt sterujący „Manager”. Ten obiekt musi otrzymać od obiektu „Registration Form” komunikat pro dodawanie studenta do wyznaczonego kursu oraz sterować innymi obiektami dla realizacji funkcji scenariusza przypadku użycia. Przypuścimy, że nazwisko studenta jest „Joe” oraz kurs jest wyznaczony jako „Math 101”. Komunikat między obiektem„Registration Form” oraz stworzonym obiektem „Manager” jest pokazany na rys.73



Rys.73


Manager to jest obiekt pośredni, który współdziała jednocześnie z formularzem oraz ze zbiorem innych obiektów - kursów edukacyjnych. Dla obsługiwania polecenia studenta musi być obiekt-kurs „Math 101”. Obiekt „Manager” musi przekazać do tego obiektu komunikat „Add Joe” (rys.74 ).

Rys.74


Obiekt – kurs nie może przyjmować samodzielnych decyzji pro dodawanie studentów do kursów nauczania. Dla dodawania studentów do kursu można definiować obiekt specjalnej klasy: „oferta kursów”. Przypuścimy, że obiekt „Section 1” jest egzemplarzem tej klasy. Obiekt-kurs „Math 101” musi z początku polecić do obiektu „Section 1” z zapytaniem, czy można dodać studenta do wyznaczonego kursu. Na diagramie stworzymy komunikat „Accepting students?pomiędzy obiektami „Math 101” oraz „Section 1”. Przypuścimy, że taka możliwość istnieje (w tym przykładzie wariant alternatywny nie będziemy rozpatrywać). Następnym komunikatem od obiektu „Math 101” do obiektu „Section 1”musi być komunikat „Add Joe” (rys.75).

Rys.75


Za edukację trzeba płacić. Wszystkie kwestie finansowe realizują się przez system zewnętrzny „Billing System”. Ten system jest reprezentowany przez obiekt „Bill”. Obiekt „Bill” realizuje interfejs do „Billing System”. Obiekt Manager przesyła się komunikat do obiektu „Bill” pro konieczność stworzenia rachunku dla wpłaty za studia oraz przesyłania tego rachunku do studenta „Joe” (rys.76 ).

Rys. 76



1   ...   25   26   27   28   29   30   31   32   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna