„Systemy oprogramowania są prawdopodobnie najbardziej skomplikowanym dziełem człowieka.”
„trzej muszkieterowie”
Wykład 3
Aspekty i zasady modelowania obiektowego
Stworzenie, omówionych już, diagramu przypadków użycia i diagramu klas zwykle zapoczątkowuje proces modelowania przyszłego systemu informatycznego, a ściśle modelowanie jego statycznych aspektów. Do wyrażenia aspektów dynamicznych modelowanego systemu służą dalsze diagramy, oferowane przez UML: diagram przebiegu, diagram kooperacji, diagram stanów, diagram czynności.
Natomiast do wyrażenia aspektów implementacyjnych służą w UML : diagram komponentów i diagram wdrożenia.
Każdy model jest uproszczeniem rzeczywistości (ma określony poziom szczegółowości i ukierunkowanie).
Modele opracowujemy po to, aby lepiej zrozumieć system, który budujemy.
Modelowanie obiektowe umożliwia wyspecyfikowanie struktury i zachowania przyszłego systemu.
Modele stanowią dokumentacje podjętych przez nas decyzji.
Modele złożonych systemów budujemy dlatego, że nie jesteśmy w stanie ogarnąć tych systemów w całości.
Nazwa przedmiotu: Inżynieria oprogramowania Egz.
Liczba godzin: 20 godz. wykładu
Wybór rodzaju modelu ma wielki wpływ na sposób przebiegu całego przedsięwzięcia a także kształt ostatecznego rozwiązania.
Żaden jeden model nie jest wystarczający. Kilka dopełniających się, powiązanych ze sobą modeli, obejmujących różne perspektywy systemu, to najlepsze rozwiązanie w przypadku każdego niebanalnego systemu.
UML jest językiem modelowania do wyrażania modeli a nie metodą, która powinna składać się, oprócz języka, również z tzw. procesu.
Procesy nie mają charakteru uniwersalnego. Pozwalają one na wpół automatycznie modelować systemy, ale o określonych własnościach.
Przykładem zunifikowanego procesu jest RUP (ang. Rational Unified Process). Oprogramowanie implementujące zarówno UML jak i RUP produkuje firma Rational Software Corp.
Jedynym dystrybutorem na Polskę jest firma Premium Technology Warszawa. Przykładem profesjonalnego narzędzia implementującego język UML jest program tej firmy pod nazwą Rational Rose Enterprise.
Modelowanie dynamiki systemu Diagramy interakcji
Interakcja to zachowanie polegające na wymianie komunikatów w grupie obiektów w pewnym celu. Diagramy interakcji modelują dynamiczne aspekty systemu. Interakcje przedstawia się jako zbiór obiektów i związków miedzy nimi, w tym komunikaty miedzy obiektami.
Komunikat definiuje się jako środek łączności miedzy obiektami, przenoszący zlecenia wykonania określonych czynności. Dwa obiekty, między którymi występuje wiązanie (associations), zwykle wysyłają do siebie komunikaty.
Efektem przekazania komunikatu jest akcja. W UML wyróżnia się pięć podstawowych rodzajów akcji:
call - Wykonanie metody obiektu, do którego
wysłany jest komunikat (obiekt może wysłać komunikat również do samego siebie),
return - Przekazanie wartości obiektowi wywołującemu,
send - Wysłanie sygnału do obiektu,
create - Utworzenie nowego obiektu,
destroy - Zniszczenie obiektu (obiekt może też popełnić samobójstwo, niszcząc sam siebie).
Istnieją dwa rodzaje diagramów interakcji: diagramy sekwencji i diagramy współdziałania.
Diagramy sekwencji
Rozważmy następujący przykładowy scenariusz pewnego przypadku użycia:
Okno wprowadzania zamówienia wysyła komunikat
„przygotuj” do Zamówienia,
Zamówienie wysyła komunikat „przygotuj” do każdej Pozycji zamówienia na Zamówieniu,
Każda Pozycja zamówienia sprawdza Towar w magazynie,
- jeśli wynik sprawdzenia jest „prawdą”, to Pozycia zamówienia zmniejsz poziom Towaru w magazynie o odpowiednia liczbę i tworzy pozycję dostawy,
- jeśli poziom Towaru w magazynie spadł poniżej wartości granicznej, to Towaru w magazynie wymaga odnowienia zapasów.
Rysunek na stronie 40 przedstawia diagram sekwencji dla powyższego scenariusza.
Chronologia wysyłania komunikatów na diagramie sekwencji jest określona sposobem czytania – od góry do dołu. W nawiasach kwadratowych można podać warunek wysłania komunikatu.
Znacznik iteracji informuje, że komunikat jest wysyłany wielokrotnie do wielu obiektów-odbiorców (na przykład w przypadku przechodzenia ciągu elementów).
Powroty z komunikatów zaznaczamy, jeśli jest to istotne dla zobrazowania interakcji.
Diagram sekwencji (przebiegu) dobrze obrazuje kolejność przesyłania komunikatów w czasie.
Natomiast diagram kooperacji (współdziałania) pokazuje organizacje strukturalną obiektów wymieniających komunikaty.
Rysunek przedstawia przykładowy diagram sekwencji.
Wracając do diagramu współdziałania, trzeba stwierdzić, że w odróżnieniu od diagramu sekwencji, pozwala on zorientować się które obiekty i jak ze sobą współdziałają w zakresie całego przypadku użycia. W celu zobrazowania następstwa
Okno
wprowadzania zamówienia
Zamówienie Towar w
magazynie Pozycja
zamówienia
przygotuj() * przygotuj()
Towar
zamówiony do magazynu
Towar dostarczony komunikat iteracja
usunięcie
powrót
utworzenie samowywołanie wMagazynie:=sprawdź()
[wMagazynie]
usuń() obiekt
czasowego, komunikaty numeruje się. Przykładowy diagram zamieszczono na stronie 49.
Zdarzenia i sygnały. Maszyna stanowa (podstawy)
Jedną z najtrudniejszych rzeczy do zrozumienia w systemach obiektowych jest ogólny przepływ sterowania w systemie.
Dobrze zaprojektowany system obiektowy ma mnóstwo małych metod w różnych klasach i czasami jest kłopotliwe odkrycie ogólnego ciągu jego zachowań. Diagramem, który dobrze obrazuje ogólny przepływ sterowania jest maszyna stanowa.
Definicje podstawowych pojęć:
Stanem (state) nazywać będziemy okoliczności, lub sytuację, w jakiej się obiekt (lub cały system) znajduje w czasie swojego życia. W szczególności - kiedy spełnia jakiś warunek, wykonuje jakąś czynność, lub czeka na jakieś zdarzenie.
Zdarzeniem (event), z punktu widzenia maszyny stanowej, nazywać będziemy każde wystąpienie bodźca, który może uruchomić przejście między stanami.
Zdarzenia asynchroniczne. Cechą charakterystyczną zdarzeń asynchronicznych jest to, że może do nich dojść w dowolnej chwili, w odróżnieniu od zdarzeń w postaci wykonania akcji, które są zdarzeniem synchronicznymi. Obiekt wywołuje wtedy operację innego obiektu a sterowanie jest przekazywane od nadawcy do odbiorcy. Następnie po wykonaniu tej operacji (i ewentualnym przejściu drugiego obiektu do innego stanu), sterowanie wraca do nadawcy.
Nie ma symboli graficznych, odróżniających sygnał od wywołania. Sygnał jest zwykle obsługiwany przez maszynę stanową, a wywołanie przez metodę.
Zdarzeniami asynchronicznymi mogą być:
- sygnały, - upływ czasu,
- wewnętrzne zmiany stanu.
Jak to już powiedziano, nie wszystkie sygnały muszą być zdarzeniami asynchronicznymi. Wewnętrzne zmiany stanu zachodzą na skutek wykonania akcji przez obiekty aktywne.
Szczegółowa definicja obiektu aktywnego zostanie podana później.
Użycie maszyny stanowej to najlepszy sposób opisu zachowań obiektów i komponentów systemu, które muszą reagować na bodźce asynchroniczne (w tym upływ czasu).
Obiekty, które mogą odbierać sygnały asynchroniczne, a także obiekty aktywne, gdyby nie miały maszyny stanowej, musiałyby ignorować te zdarzenia asynchroniczne.
Maszyny stanowe opisują również zachowanie całych systemów, które w sposób interaktywny odpowiadają na sygnały pochodzące od aktorów z otoczenia systemu.
Cechą charakterystyczną maszyny stanowej jest możliwość opisu faktu, że przejścia między stanami mogą zależeć od historii przejść systemu.
Bezczynność
Konserwacja konserwuj
Obsługa
Weryfikacja
Wybór
Realizacja
Drukowanie Weryfikacja
Wybór
Realizacja
Drukowanie [kontynuacja]
[ not kontynuacja]
kartaWsunięta anulowano
entry/odczytajKartę exit/wysuńKartę
Maszyna stanowa – modelowanie historii życia systemu BANKOMAT. Wykonano przy użyciu Rational Rose.
Komentarz do rysunku powyżej:
1. Stany początkowe (dwa) oznaczono wypełnionymi kółkami (nie są istotne).
2. Sygnałami asynchronicznymi są: konserwuj, kartaWsunięta oraz anulowano. Pozostałe przejścia opisują zmiany stanu na skutek zakończenia akcji wykonywanych w danym stanie.
3. Obsługa jest nazwą stanu złożonego. Stan ten posiada akcję wejściową i dwie akcje wyjściowe.
4. Stan złożony może zaczynać się od swojego stanu początkowego (jak w naszym przykładzie), bądź od wskazanego podstanu, lub podstanów.
5. Determinizm wymaga, aby w przypadku możliwości kilku przejść z danego stanu do innych stanów, przejścia były dozorowane w sposób wzajemnie się wykluczający.
Tutaj dozory [kontynuacja] i [not kontynuacja].
6. W celu uproszczenia diagramu maszyny stanowej nie opisano, w jakim podstanie stanu Obsługa możliwe jest wysłanie sygnału anulowano.
7. Dojście do pewnych stanów, np. Bezczynność, jest związane z pewnymi konkretnymi historiami przejść systemu przez określone ciągi stanów.
Modelowanie upływu czasu
Wpływ upływu czasu na zdarzenia modeluje się za pomocą:
zdarzenia zmiany z parametrem w postaci czasu (zdarzenie zmiany jest pojęciem ogólniejszym i reprezentuje przejście miedzy stanami po spełnieniu pewnego warunku),
zdarzenia czasowego ze słowem kluczowym after.
Można posługiwać się czasem bezwzględnym, lub względnym (wtedy domyślnie przyjmuje się za początek upływu czasu moment przyjęcia stanu bieżącego przez obiekt).
Bezczynność
Aktywność after(2s) / przerwijPołączenie() when(23:59) / autoTest()
Przykłady modelowania upływu czasu Wykonano przy użyciu Rational Rose.
Zdarzenie zmiany
Zdarzenie czasowe
Wysyłanie i odbieranie zdarzeń
Po wysłaniu sygnału jako zdarzenia asynchronicznego, nadawca kontynuuje swoje czynności.
Obiekt, który wywołuje operację synchronicznie, czeka na reakcję odbiorcy. Np. w systemie obsługi wymiany handlowej egzemplarz klasy Kupiec po wywołaniu operacji potwierdźTransakcję() na egzemplarzu klasy Towar będzie czekał na zakończenie operacji.
Jeśli zdarzenie wywołania jest synchroniczne, przepływ sterowania nadawcy zostaje zablokowany przez przepływ sterowania odbiorcy do chwili, w której zakończy się operacja. Mówimy o spotkaniu nadawcy i odbiorcy na czas realizacji operacji.
Po wysłaniu sygnału asynchronicznego nie dochodzi do spotkania nadawcy i odbiorcy. Nadawca po wysłaniu sygnału nie czeka na odpowiedź odbiorcy.
Sygnały, które są operacjami asynchronicznymi, umieszcza się normalnie w sekcji operacji klasy.
Nazwane sygnały, które obiekt musi odebrać wymienia się w dodatkowej sekcji symbolu klasy. W ten sposób zapisuje się sygnały związane z interfejsami klasy.
Zdarzenie wysyłania sygnału do wielu obiektów jednocześnie nazywamy rozsyłaniem do wszystkich obiektów systemu, lub rozgłaszaniem.
Modelowanie procesów współbieżnych Podstawowe definicje:
Proces (process) to ”ciężki” przepływ sterowania, który może się wykonywać współbieżnie z innymi procesami.
Wątek (thread) to ”lekki” przepływ sterowania, który może się wykonywać z innymi wątkami w ramach jednego procesu.
Obiekt aktywny to obiekt, który jest właścicielem procesu lub wątku i może uruchomić niezależne sterowanie.
Klasa aktywna to klasa, której egzemplarze są obiektami aktywnymi. Pozostałe klasy nazywamy pasywnymi.
Węzeł to fizyczny składnik systemu informatycznego. Ma zwykle pewna ilość pamięci i zdolność przetwarzania.
Metka to możliwość wzbogacenia określonego bytu UML (klasy, węzła, komponentu, itd.) o nowe własności mające znaczenie w generowaniu kodu i zarządzaniu konfiguracjami.
ZarządcaPanelu nrPanelu: Integer Signals
naciśniętoPrzycisk(p:Przycisk) włączonoZasilanie
wyłączonoZasilanie Atrybut
klasy
Sygnały odbierane przez klasę aktywną
Przykładowa klasa aktywna
W UML każdy niezależny przepływ sterowania jest modelowany w postaci obiektu aktywnego.
Modelując system współbieżny za pomocą takich obiektów, nadajemy nazwę każdemu niezależnemu przepływowi sterowania. Z chwilą utworzenia obiektu aktywnego, zostaje uruchomiony związany z nim przepływ sterowania. Zniszczenie obiektu przerywa ten przepływ sterowania.
Klasy aktywne modelują zatem rodziny podobnych procesów, lub wątków.
W systemie sekwencyjnym, w którym istnieje tylko jeden przepływ sterowania, jeśli w otoczeniu systemu dochodzi do wielu współbieżnych zdarzeń (wywołanych przez różnych aktorów), zdarzenia te muszą być kolejkowane, lub ignorowane.
W systemie współbieżnym istnieje jednocześnie wiele przepływów sterowania. Każdy z nich związany jest z jednym, niezależnym wątkiem, lub procesem. W danej chwili w programie może być wiele miejsc jego wykonywania się.
Języki Java, Smalltalk i Ada mają wbudowaną współbieżność, C++ wspomaga współbieżność poprzez biblioteki oparte na mechanizmach współbieżności systemu operacyjnego.
Prawdziwą współbieżność można osiągnąć trzema metodami:
1. Rozpraszając obiekty aktywne na wielu węzłach,
2. Umieszczając obiekty aktywne na węzłach z wieloma procesorami,
3. Łącząc powyższe, dwie metody.
Własności procesów:
Proces, jako ciężki przepływ sterowania, jest rozpoznawany przez system operacyjny i wykonywany w niezależnej przestrzeni adresowej.
Bardzo często wszystkie procesy danego węzła są równorzędne i rywalizują o te same dostępne w nim zasoby.
Procesy nigdy nie są w sobie zagnieżdżone.
Własności wątków:
Watek, jako lekki przepływ sterowania, najczęściej nie jest rozpoznawany przez system operacyjny i wykonywany jest w przestrzeni adresowej otaczającego go procesu.
Wszystkie wątki w ramach jednego procesu są równorzędne i rywalizują o te same dostępne w procesie zasoby.
Wątki nigdy nie są w sobie zagnieżdżone.
Ponieważ to nie wątki, a procesy, podlegają mechanizmom szeregowania w węźle przez system operacyjny, de facto mamy tu do czynienia tylko z wrażeniem współbieżności.
W języku Java wątek jest potomkiem klasy Thread.
Własności klas aktywnych:
Klasy aktywne mają te same własności, co zwykłe klasy (pasywne), tzn.:
- mają egzemplarze, atrybuty i operacje,
- uczestniczą w: zależnościach, uogólnieniach, powiązaniach (w tym w agregacjach),
- mogą być realizacjami interfejsów,
- mogą być realizowane przez kooperacje,
- ich zachowanie może być definiowane za pomocą maszyny stanowej.
Często w celu rozszerzenia właściwości klasy aktywnej używa się metek,
np. {location= stacja klienta},
Klasy aktywne występują w diagramach klas obrazując statyczne własności perspektywy procesowej systemu realizującego wiele współbieżnych przepływów sterowania.
Własności obiektów aktywnych:
Obiekty aktywne mogą wystąpić na diagramach w tych samych miejscach, co obiekty pasywne),
najczęściej spotkamy je w diagramach interakcji (kooperacji i przebiegu).
Obiekty aktywne, podobnie jak pasywne, mogą wysyłać i odbierać sygnały, a także zdarzenia wywołania.
Komunikacja
s : SterownikTablicy
t : Tablica
: ŹródłoWiedzy 1. s1:inicjuj()
2. maWskazówkę(w)
3. s2:zacznijPoszukiwania() 4. s3:w.oceńWartość()
4. :umieśćRozwiązanieCzęściowe()
Modelowanie komunikacji miedzyobiektowej
obiekt aktywny
obiekt aktywny
obiekt aktywny komunikat
synchroniczny
Wykonano przy użyciu Rational Rose.
Wymiana komunikatów w systemie zawierającym zarówno obiekty aktywne, jak i pasywne:
Przekazywanie komunikatów:
Przebieg interakcji:
pomiędzy dwoma obiektami pasywnymi
w ramach jednego przepływu sterowania jest to zwykłe wywoływanie operacji
jest to komunikacja miedzy dwoma procesami:
pomiędzy dwoma obiektami aktywnymi
gdy jeden obiekt aktywny może synchronicznie wywoływać operacje drugiego obiektu
aktywnego spotkanie, w czasie którego oba przepływy sterowania są ze sobą ściśle związane (wywołujący czeka na
potwierdzenie wywołania, wywołany realizuje operacje i przekazuje ewentualny wynik
wywołującemu, który kończy spotkanie)
gdy ma miejsce asynchroniczne wysłanie sygnału bądź
wywołanie operacji
komunikacja typu skrzynki pocztowej (oba obiekty nie są ze sobą zsynchronizowane)
od obiektu aktywnego do pasywnego
duże znaczenie odgrywa synchronizacja
procesów, bowiem problemem jest sytuacja, w której kilka obiektów aktywnych wysyła w tym samym czasie sygnały do jednego obiektu
pasywnego od obiekty
pasywnego do aktywnego
przebieg podobny, jak miedzy dwoma obiektami aktywnymi
Synchronizacja
Definicje:
1. Mówimy, że w danej chwili sterowanie znajduje się w pewnej operacji, gdy jakiś przepływ przemierza właśnie tę operację.
2. Mówimy też, że w danej chwili sterowanie znajduje się w konkretnym obiekcie pewnej klasy, gdy jakiś przepływ przemierza operacje tej klasy.
3. W jednej operacji może być jednak wiele jednoczesnych przepływów sterowania ( a zatem i w jednym obiekcie ).
4. Sytuacja powyższa prowadzi do wzajemnego wykluczania się przepływów sterowania. Gdyby jej nie zapobiec, może to doprowadzić do powstania takich zjawisk, jak wyścigi i kolizje i w konsekwencji do zniekształcenia stanu obiektu, którego dotyczy.
Rozwiązaniem jest dodanie pewnych właściwości synchronizujących do operacji krytycznych, zdefiniowanych w klasie. W językach wspomagających współbieżność (np. Java) można zapisać opisane niżej własności za pomocą semaforów.
Właściwości synchronizujące języka UML:
1. sequential - polega na dbaniu o to, aby w każdej chwili w obiekcie był tylko jeden przepływ sterowania,
2. guarded - polega na szeregowaniu wywołań wszystkich chronionych operacji
obiektu. W danej chwili może więc być wykonywana tylko jedna operacja,
3. concurrent - polega na traktowaniu wszystkich
operacji jako niepodzielnych ( W Javie właściwości tej odpowiada właściwość synchronized ).
Realizacja tych właściwości powoduje, że wszystkie operacje realizowane są w gruncie rzeczy sekwencyjnie.
Właściwości synchronizujące klasy aktywnej Komentarz do rysunku na str. 53:
1. Trzy aktywne obiekty d, m i i dostarczają tu współbieżnie informacji do systemu.
2. Obiekty d i m porozumiewają się, każdy ze swoim egzemplarzem (a1, a2) klasy Analityk.
3. Oba egzemplarze klasy Analityk mogą porozumiewać się równolegle z egzemplarzem o klasy ObsługaAlarmów (o to typowy obiekt aktywny).
4. Podobnym obiektem jest t, który może współbieżnie przyjmować komunikaty od obiektu o oraz i klasy InformacjeCNN.
5. Obiekty o i t to miejsca przecięć ścieżek różnych przepływów sterowania, a więc punkty w których należy zwrócić szczególna uwagę na problemy komunikacji i synchronizacji.
Bufor rozmiar: Integer dodaj(){concurrent}
usuń() {concurrent}
Operacje
Właściwości synchronizujące
d : DalekopisGiełdowy
a1 : Analityk
o : ObsługaAlarmów
a2 : Analityk m :
MonitorIndeksowy
t : ObsługaTransakcji
i : InformacjeCNN 1. k1:wyślijWartość()
2. k2:wyślijSygnałAlarmowy()
3. m2:wyślijSygnałAlarmowy()
5. o1:wyślijSygnałAlarmowy()
4. m1:wyślijWartość()
6. i1:wyślijTabelęKursów()
Fragment diagramu współdziałania, obrazującego modelowanie wielu przepływów sterowania. Wykonano przy użyciu Rational Rose.
Modelowanie komunikacji międzyprocesowej
W systemach rozproszonych procesy mogą się wykonywać na odrębnych węzłach.
Klasyczne rodzaje komunikacji międzyprocesowej, to:
- asynchroniczne przekazywanie komunikatów, - zdalne wywołania procedur (synchroniczne), W UML mechanizmy komunikacyjne opisujemy
zwyczajowo za pomocą notatek, lub bardziej formalnie za pomocą kooperacji.
obiekt aktywny obiekt
pasywny komunikat
synchroniczny
COBRA ORB
r {location=serwer systemu rezerwacji} : ObsługaRezerwacji
<<process>>
t {location=stacja klienta} : InformatorTurystyczny
<<process>>
h {location=serwer hotelowy} : AgentHotelowy
<<process>>
b {location=serwer linii lotniczej} : PrzydziałBiletów
<<process>>
Komunikacja przez usługi przesyłania komunikatow Java Beans
2. r1:dokonaj()
3. r2:dokonaj() 1. t1:zaplanujTrasę()
4. r3:przekażWyniki()
Model rozproszonego systemu rezerwacji, działającego na czterech węzłach. Wykonano przy użyciu Rational Rose.
Komentarz do rysunku powyżej:
1. Obiekt t działa jak klient, natomiast obiekt r, jak serwer.
2. Szczegóły interakcji między obiektami r i t opisuje kooperacja COBRA ORB.
Dobrze zbudowana klasa aktywna, lub obiekt aktywny:
nie jest zbyt drobnoziarnista, tzn. nie prowadzi do zbyt złożonej i kruchej architektury systemu,
wyraźnie rozróżnia procesy i wątki,
na diagramie UML ujawnia jedynie te atrybuty, operacje, sygnały i komunikaty, które są niezbędne do zrozumienia roli klasy lub obiektu aktywnego w bieżącym otoczeniu,
efektywnie korzysta z trybu synchronicznego i asynchronicznego komunikacji miedzyobiektowej.
