Projektowanie systemw informacyjnych Wykad 9 Diagramy dynamiczne 1

  • Slides: 30
Download presentation
Projektowanie systemów informacyjnych Wykład 9 Diagramy dynamiczne (1) Kazimierz Subieta, Ewa Stemposz Instytut Podstaw

Projektowanie systemów informacyjnych Wykład 9 Diagramy dynamiczne (1) Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 1

Zagadnienia Asocjacje n-arne Klasyfikatory i wystąpienia Diagramy definiowane w UML Modele w UML Diagramy

Zagadnienia Asocjacje n-arne Klasyfikatory i wystąpienia Diagramy definiowane w UML Modele w UML Diagramy interakcji § Diagramy współpracy § Diagramy sekwencji Generyczne diagramy interakcji § Wyrażanie warunków § Wyrażanie iteracji Współbieżność na diagramach interakcji K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 2

Asocjacje n-arne Asocjacja n-arna to asocjacja, której wystąpienia łączą n obiektów, będących instancjami co

Asocjacje n-arne Asocjacja n-arna to asocjacja, której wystąpienia łączą n obiektów, będących instancjami co najwyżej n klas: 3 -arna - 3 obiekty (inna nazwa dla tej asocjacji to ternarna), 4 -arna - 4 obiekty, itd. Dana klasa może pojawić się na więcej niż jednej pozycji w asocjacji. Asocjacja binarna ze swoją uproszczoną notacją i pewnymi dodatkowymi własnościami (takimi jak możliwość ustalania kierunku nawigowania, kwalifikatorów, związków agregacji czy kompozycji) jest specjalnym rodzajem asocjacji n-arnej (dla n=2). Asocjacja binarna i 2 -arna są równoważne, nie istnieje między nimi różnica semantyczna, inny jest tylko sposób reprezentowania. Wymienione wyżejdodatkowe własności asocjacji binarnych są zabronione dla asocjacji n-arnych, gdzie n > 2. asocjacja 4 -arna asocjacja 3 -arna Notacja K 1 K 3 K 1 nazwa asocjacji K 2 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 3 K 2

Asocjacje n-arne; liczności Liczności Specyfikowanie liczności dla asocjacji n-arnych nie jest tak oczywiste, jak

Asocjacje n-arne; liczności Liczności Specyfikowanie liczności dla asocjacji n-arnych nie jest tak oczywiste, jak dla asocjacji binarnych i różni autorzy wygłaszają na ten temat różne zdania. UML odrzuciła poglądy, że liczność danej roli powinna być ustalana w odniesieniu do liczności pozostałych ról, traktowanych oddzielnie. Przyjęto zasadę, że liczność n-tej roli jest opisana przez zbiór możliwych wartości liczności, gdy sytuacja na n-1 końcach asocjacji jest ustalona. Np. dla ternarnej asocjacji łączącej klasy A, B i C liczność roli C specyfikuje, ile obiektów klasy C jest powiązanych z każdą możliwą parą obiektów klas A i B. Taka reguła jest zgodna z regułą przyjętą dla specyfikowania liczności asocjacji binarnych. Atrybuty Rok * Zespół * sezon Zapis * Gracz bramkarz Mecz K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 4 gole nasze gole ich zwycięstwa przegrane remisy

Obejście asocjacji n-arnej Asocjacje n-arne mają sens wtedy, gdy do identyfikacji powiązania (n-arnego) potrzebne

Obejście asocjacji n-arnej Asocjacje n-arne mają sens wtedy, gdy do identyfikacji powiązania (n-arnego) potrzebne są wszystkie obiekty, tzn. gdy liczność każdej z ról jest “wiele”. W pozostałych przypadkach asocjację n-arną warto jest zastępować asocjacjami binarnymi, które są łatwiejsze do implementacji i wyposażone w dodatkowe własności, o których była mowa poprzednio. Niestety traci się informację o związku, łączącym grupę obiektów w pewną całość. K 2 K 1 K 2 K 3 K 1 a 2 K 3 m 1 KA a 1 a 2 KA Asocjacja n-arna zostaje zamieniona na klasę i n asocjacji binarnych. m 1 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 5

Klasyfikatory i wystąpienia W UML pojęcie klasyfikatora związane jest z bytem stanowiącym opis własności

Klasyfikatory i wystąpienia W UML pojęcie klasyfikatora związane jest z bytem stanowiącym opis własności zbioru wystąpień (instancji). Poniższa tabela specyfikuje przykładowe pary: klasyfikator/wystąpienie. Klasyfikator Wystąpienie klasa obiekt use case scenariusz aktor komponent podsystem UML traktuje wszystkie pary klasyfikator/wystąpienie w jednolity sposób, np. zawsze taka sama ikona jest używana dla klasyfikatora i wystąpienia, np. prostokąt dla klasy i obiektu czy “człowieczek” dla aktora-klasyfikatora oraz aktora-wystąpienia. Ikona dla wystąpienia jest etykietowana przez Nazwa. Wystąpienia: Nazwa. Klasyfikatora (nazwa wystąpienia może być opuszczana; dwukropek pozostaje). W przypadku, gdy ikona reprezentuje klasyfikator jest etykietowana wyłącznie jego nazwą (bez podkreślenia). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 6

Diagramy definiowane w UML Diagramy przypadków użycia Diagramy klas, diagramy obiektów Diagramy dynamiczne (zachowania):

Diagramy definiowane w UML Diagramy przypadków użycia Diagramy klas, diagramy obiektów Diagramy dynamiczne (zachowania): § Diagramy interakcji Diagramy sekwencji Diagramy współpracy (kolaboracji) § Diagramy stanów § Diagramy aktywności Diagramy implementacyjne: § Diagramy komponentów § Diagramy wdrożeniowe Diagramy pakietów Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 7

Modele w UML Model - pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na

Modele w UML Model - pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na określonym poziomie szczegółowości. Diagram - środek służący do opisu modelu. Model może być opisany przy pomocy wielu diagramów. Dany element modelu może pojawiać się na wielu diagramach prezentowanego modelu. Dwa najważniejsze modele w UML to: § model przypadków użycia opisujący system widziany z perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia), § model obiektów przedstawiający statyczną budowę, czyli strukturę systemu (za pomocą diagramów klas i diagramów obiektów). Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty. Model dynamiczny, opisywany za pośrednictwem diagramów dynamiczych, opisuje zachowanie systemu podczas realizacji zadań, gdzie zadanie może stanowić realizacja pojedynczego przypadku użycia lub jednego konkretnego scenariusza danego przypadku użycia (dla systemów bez współbieżności). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 8

Diagramy interakcji, stanowiące jeden z rodzajów diagramów dynamicznych, pozwalają na utworzenie opisu interakcji obiektów

Diagramy interakcji, stanowiące jeden z rodzajów diagramów dynamicznych, pozwalają na utworzenie opisu interakcji obiektów systemu podczas realizacji danego zadania: przypadku użycia czy jednego konkretnego scenariusza danego przypadku użycia. Nie dla wszystkich przypadków użycia może zachodzić potrzeba konstruowania diagramów interakcji, ale mogą okazać się szczególnie użyteczne np. do komunkacji wewnątrz zespołu projektowego (jak zresztą wszystkie rodzaje diagramów) czy też do rozważenia opcjonalnych realizacji w “trudnych przypadkach”. Ponadto, niektóre narzędzia CASE potrafią wykorzystać te diagramy do generacji kodu, co może stanowić ważny powód dla ich konstruowania. UML posiada dwa rodzaje diagramów interakcji: § diagramy współpracy (kolaboracji) i § diagramy sekwencji. Oba rodzaje diagramów, bazując na danym diagramie klas, pokazują prawie tą samą informację, w nieco inny sposób. Niektóre narzędzia CASE potrafią generować jedne z tych diagramów z drugich. Decyzja, który rodzaj diagramów konstruować, zależy od pożądanego aspektu interakcji. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 9

Diagramy współpracy; przykład Diagramy współpracy pokazują w jaki sposób system realizuje dany przypadek użycia.

Diagramy współpracy; przykład Diagramy współpracy pokazują w jaki sposób system realizuje dany przypadek użycia. Współpracujące obiekty, połączone liniami nazywanymi tu “linkami”, stanowią rodzaj “kolektywu”, zwanego tu kolaboracją. Linki odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia asocjacja musi istnieć na diagramie klas. inicjator : Personel bibl. : Członek bibl. Można tu pokazywać też informacje w rodzaju: : Książka : Egzemplarz książki § kierunek nawigowania, § nazwy linków, § itp. , jak w modelu klas pod warunkiem, że zwiększą, a nie zmniejszą czytelność diagramu. Prosty diagram współpracy, bez uwidaczniania interakcji między obiektami, stanowi coś w rodzaju “wystąpienia fragmentu diagramu klas”; pokazuje aktora, relewantne obiekty i powiązania między nimi. Możliwe jest pokazanie więcej niż jednego obiektu danej klasy. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 10

Interakcja na diagramach współpracy (1) Diagramy współpracy mogą dodatkowo pokazywać interakcje zachodzące między obiektami

Interakcja na diagramach współpracy (1) Diagramy współpracy mogą dodatkowo pokazywać interakcje zachodzące między obiektami zaangażowanymi w realizację danego przypadku użycia. Sekwencja interakacji oznacza tu sekwencję komunikatów przesyłanych między współpracującymi obiektami. komunikat wysyłany przez aktora do obiektu klasy Członek bibl. : Personel bibl. Pożycz (egzemplarz) : Członek bibl. : Książka 3: Zaznacz. Wypożyczenie : Egzemplarz książki 2: Pożycz 1: Czy. Można. Pożyczyć Komunikaty przedstawiane są tu w postaci etykiet strzałek rysowanych wzdłuż linków między kolaborującymi obiektami. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 11

Interakcja na diagramach współpracy (2) Obiekt, adresat komunikatu musi go rozumieć, co oznacza, że

Interakcja na diagramach współpracy (2) Obiekt, adresat komunikatu musi go rozumieć, co oznacza, że klasa której jest wystąpieniem musi dostarczyć (definiować) tę operację. Konstruowanie diagramów interakcji może pomóc w identyfikowaniu zarówno asocjacji między klasami, jak i operacji w klasach, a przez to może prowadzić do korekty diagramu klas, i temu celowi zresztą głównie służy. Jest oczywistym, że oba modele (obiektów i dynamiczny) muszą być spójne. Rodzaje interakcji: § Sekwencyjna - tylko jeden aktor może zainicjować sekwencję komunikatów i w danym momencie tylko jeden obiekt może “działać”. Obiekt rozpoczyna tzw. “aktywne życie” (live activation) w momencie otrzymania komunikatu. Może wysłać odpowiedź do nadawcy komunikatu. W międzyczasie może prowadzić obliczenia czy też wysyłać komunikaty do innych obiektów. Wysyłając komunikat do innego obiektu nadal pozostaje w aktywnym stanie, ale jego własna działalność zostaje zawieszona do czasu otrzymania odpowiedzi na wysłany komunikat - wysyłanie komunikatu zwiazane jest tu z przekazywaniem sterowania do odbiorcy komunikatu. W każdym momencie istnieje w systemie stos aktywnych obiektów; na szczycie stosu znajduje się ten obiekt, który aktualnie “działa”. Wysłanie odpowiedzi na komunikat powoduje zdjęcie obiektu ze stosu. § Współbieżna. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 12

Interakcja na diagramach współpracy (3) Na diagramach współpracy nie pokazuje się odpowiedzi na wysyłane

Interakcja na diagramach współpracy (3) Na diagramach współpracy nie pokazuje się odpowiedzi na wysyłane komunikaty. Komunikaty mogą być numerowane, albo kolejnymi liczbami naturalnymi (jak na poprzednim diagramie), albo stosując tzw. numerację zagnieżdżoną. W obu przypadkach, z reguły, nie bierze się pod uwagę komunikatu wysyłanego od aktora. : Książka : Personel bibl. Pożycz (egzemplarz) : Członek bibl. 2. 1: Zaznacz. Wypożyczenie : Egzemplarz książki 2: Pożycz 1: Czy. Można. Pożyczyć Numeracja zagnieżdżona, oznacza, że jeśli obiekt O otrzyma komunikat o numerze np. 7. 3 to ten numer będzie dołączany jako prefix do każdego komunikatu wysyłanego w trakcie realizacji komunikatu 7. 3 przez O. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 13

Diagramy sekwencji nie pokazują linków między współpracującymi obiektami, ale można to wydedukować w oparciu

Diagramy sekwencji nie pokazują linków między współpracującymi obiektami, ale można to wydedukować w oparciu o zaznaczone komunikaty. : Personel bibl. : Członek bibl. : Egzemplarz książki : Książka linia życia obiektu Pożycz (egzemplarz) czas 1: Czy. Można. Pożyczyć aktywne życie obiektu 2: Pożycz 2. 1: Zaznacz. Wypożyczenie Kolejność obiektów nie ma tu znaczenia, ale warto zadbać o czytelność. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 14

Ilustracja przekazywania sterowania Na diagramach sekwencji, wyraźniej niż na diagramach współpracy, można pokazać przekazywanie

Ilustracja przekazywania sterowania Na diagramach sekwencji, wyraźniej niż na diagramach współpracy, można pokazać przekazywanie sterowania. : Personel bibl. : Członek bibl. : Egzemplarz książki : Książka Pożycz (egzemplarz) 1: Czy. Można. Pożyczyć 2: Pożycz 2. 1: Zaznacz. Wypożyczenie K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 15

Nakładanie ograniczeń na przepływ czasu (1) Główna przewaga diagramów sekwencji nad diagramami kolaboracji przejawia

Nakładanie ograniczeń na przepływ czasu (1) Główna przewaga diagramów sekwencji nad diagramami kolaboracji przejawia się w ich zdolności do graficznego prezentowania przepływu czasu, a nawet do podawania ograniczeń czasowych, czy też - co może być kontrowersyjne - skali czasowej. Taka możliwość może mieć duże znaczenie dla opisu systemów czasu rzeczywistego. : Dzwoniący {b - a < 1 sec. } : Sterowanie a podniesienie słuchawki b ton w słuchawce c wybór cyfry {c - b < 10 sec. } Rozmowa d jest łączona d’ poprzez sieć {d’ - d < 5 sec. } : Odbierający . . . łączenie ton dzwonka uruchomienie dzwonka podniesienie słuchawki koniec tonu K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 16 koniec dzwonienia

Nakładanie ograniczeń na przepływ czasu (2) : Personel bibl. A : Członek bibl. :

Nakładanie ograniczeń na przepływ czasu (2) : Personel bibl. A : Członek bibl. : Egzemplarz książki Pożycz (egzemplarz) : Książka gdy interesuje nas czas wykonania komunikatu 1: Czy. Można. Pożyczyć { Zaznacz. Wypożyczenie Pożycz < 1 sek. } {C-A < 5 sek. } 2: Pożycz 2. 1: Zaznacz. Wypożyczenie c Dwa sposoby opisywania czasu: oznaczanie skali czasowej lub nakładanie ograniczeń na upływ czasu. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 17

Wartości zwracane; tworzenie i usuwanie obiektów na diagramach sekwencji Czasami przydaje się uwidocznienie wartości

Wartości zwracane; tworzenie i usuwanie obiektów na diagramach sekwencji Czasami przydaje się uwidocznienie wartości zwracanej przez komunikat, poprzez instrukcję przypisania. Umożliwia to późniejsze wykorzystanie tej wartości, np. jako argumentu dla innego komunikatu. Może też być wykorzystana do specyfikowania warunku czy iteracji. : Wykładowca nowy obiekt pojawia się na diagramie w miejscu korespondującym z czasem jego utworzenia : Sekretariat ds. nauczania n : = Pobierz. Nazwisko Utwórz. Nowego. Szefa. Wykładowców (n) usuń : Szef wykładowców X koniec życia obiektu K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 18 Wykładowca Szef wykładowców

Wartości zwracane; tworzenie i usuwanie obiektów na diagramach współpracy 1: n : = Pobierz.

Wartości zwracane; tworzenie i usuwanie obiektów na diagramach współpracy 1: n : = Pobierz. Nazwisko : Wykładowca {usuwany} : Sekretariat ds. nauczania 3: usuń 2: Utwórz. Nowego. Szefa. Wykładowców (n) : Szef wykładowców {nowy} własność (property) Komunikaty wysyłane od aktora są tu numerowane, aby można było ustalić ich kolejność. Projekt musi specyfikować, kto jest odpowiedzialny za usuwanie obiektów, aby zapobiec tzw. “wyciekaniu pamięci”. Niektóre języki, takie jak np. Java czy Small. Talk, posiadają wbudowane mechanizmy zbierania nieużytków (garbage collectors). Z grubsza, polega to na usuwaniu (w jakimś czasie) wszystkich obiektów, do których nie ma żadnych referencji w systemie. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 19

Generyczne diagramy interakcji (1) W UML, generyczny diagram interakcji ma specyfikować wszystkie sekwencje interakcji

Generyczne diagramy interakcji (1) W UML, generyczny diagram interakcji ma specyfikować wszystkie sekwencje interakcji dla danego przypadku użycia, a nie tylko dla jednego z możliwych scenariuszy. Diagram dla pojedynczego scenariusza jest tu nazywany wystąpieniem generycznego diagramu interakcji. Ponieważ diagramy generyczne mogą w niektórych przypadkach okazać się zbyt złożone, dopuszcza się rozwiązania połowiczne. Przedstawianie zachowań warunkowych Wysłanie komunikatu może być uzależnione od spełnienia wyspecyfikowanego warunku. : K jeśli i nie będzie zmienione w międzyczasie dwa różne punkty w czasie : K ten sam punkt w czasie [i = 0] x [i = 1] y W zależności od wartości i oba komunikaty (x i y) mogą nie być wysłane. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 20 {warunki muszą się wykluczać} Może być wysłany albo komunikat x albo y. Może też nie być wysłany żaden z nich.

Generyczne diagramy interakcji (2) Warunek, zapisany wewnątrz nawiasów [ ] stanowi wyrażenie typu Boolean

Generyczne diagramy interakcji (2) Warunek, zapisany wewnątrz nawiasów [ ] stanowi wyrażenie typu Boolean i może być wyrażony w języku naturalnym, w języku ustrukturalizowanym (np. OCL), w języku programowania czy innej notacji. : K 1 : K 2 7. 1: [i = 0] x Linia życia dla wystąpienia klasy K 2 uległa rozgałęzieniu, aby podkreślić fakt, że stan obiektu może wyglądać inaczej w zależności od tego, który komunikat zostanie wysłany. 7. 2: [i = 1] y Budzi wątpliwości numeracja komunikatów, może wykonać się tylko jedna z nich. Być może obie powinny być oznaczone przez 7. 1. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 21

Generyczne diagramy interakcji (3) Wyrażanie warunków na diagramach współpracy jest także możliwe. Nie da

Generyczne diagramy interakcji (3) Wyrażanie warunków na diagramach współpracy jest także możliwe. Nie da się tu jednak pokazać rozgałęzienia linii życia obiektu. Dlatego wydaje się, że poza najprostszymi sytuacjami, diagramy sekwencyjne lepiej modelują realizację bardziej złożonych (z opcjonalnymi scenariuszami) przypadków użycia. Przedstawianie iteracji UML umożliwia oznaczenie komunikatu, który ma być wysłany wiele razy, poprzez poprzedzenie go symbolem *. Oczywiście musi być też wyspecyfikowany warunek, określający zakończenie iteracji. Przykłady iteracji: *[i : = 1. . 10] - komunikat będzie wysłany 10 razy, *[x < 10] - komunikat będzie wysyłany dopóki x będzie < 10, *[pozycja znaleziona] - komunikat będzie wysyłany do momentu, gdy pozycja nie zostanie znaleziona (gdy warunek przyjmie wartość FALSE) Jeśli w trakcie wielokrotnego wysyłania komunikatu x, będzie wysyłany także komunikat y, to zostanie on wysłany tyle razy, ile razy wysyłane jest x. Zachowanie spójności diagramów nie wymaga powtarzania symbolu iteracji dla komunikatu y. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 22

Generyczne diagramy interakcji (4) : K 1 : K 2 3. 1: *[i :

Generyczne diagramy interakcji (4) : K 1 : K 2 3. 1: *[i : = 1. . 2] x xyxy 3. 1. 1: y : K 1 xyyy : K 3 : K 2 : K 3 3. 1: *[i : = 1. . 2] x 3. 1. 1: *[j : = 1. . 3] y sekwencja komunikatów K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 23

Współbieżność na diagramach interakcji Dla interakcji sekwencyjnych nadawca komunikatu oczekuje na odpowiedź odbiorcy zawieszając

Współbieżność na diagramach interakcji Dla interakcji sekwencyjnych nadawca komunikatu oczekuje na odpowiedź odbiorcy zawieszając własną działalność w trakcie oczekiwania. W danym momencie czasu działa tylko jeden obiekt i wysyłany może być tylko jeden komunikat. Takie systemy nazywane są też czasami proceduralnymi lub jedno-wątkowymi. Prosta definicja sytemu współbieżnego mówi: wiele obiektów może działać jednocześnie, wiele komunikatów może być wysyłanych w tym samym czasie. Do systemów współbieżnych możemy zaliczyć, np. : § systemy rozproszone - przetwarzanie zachodzi równocześnie na wielu procesorach w różnych miejscach, § wielowątkowe aplikacje - przetwarzanie równoległe na wielu procesorach lub na jednym procesorze z podziałem czasu. Przetwarzanie współbieżne jest często mylone z przetwarzaniem w czasie rzeczywistym, ponieważ systemy czasu rzeczywistego są często współbieżne i vice versa. Jednakże idee leżące u podłoża obu rodzajów systemów są różne: system jedno-wątkowy może być systemem czasu rzeczywistego, podczas gdy współbieżny może takim systemem nie być. Dla systemu czasu rzeczywistego istotne jest wypełnianie ograniczeń czasowych. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 24

Modelowanie wielu wątków sterowania Rozpoczęcie nowego wątku sterowania jest możliwe poprzez: Rozdzielenie istniejącego wątku

Modelowanie wielu wątków sterowania Rozpoczęcie nowego wątku sterowania jest możliwe poprzez: Rozdzielenie istniejącego wątku na kilka innych. Obiekt, który działa (bo otrzymał komunikat) może wysłać jednocześnie kilka synchronicznych komunikatów. Synchroniczność oznacza tu, że będzie oczekiwał na zakończenie wszystkich. Na diagramie sekwencji byłoby to uwidocznione przez pokazanie komunikatów wysyłanych w tym samym punkcie czasowym, jak już było prezentowane wcześniej, ale tym razem bez ograniczenia, że warunki muszą się wzajemnie wykluczać. Na diagramach kolaboracji można używać nazw (pojedynczego znaku lub łańcucha znaków) na oznaczenie współbieżności komunikatów: np. 2. 10. A jest współbieżne z 2. 10. B dla aktywności spowodowanej wysłaniem komunikatu 2. 10, w przeciwieństwie do 2. 10. 1 i 2. 10. 2, które oznaczają komunikaty synchroniczne. Aktor, może wysłać nowy komunikat w trakcie przetwarzania systemu. Obiekt może wysłać asynchroniczny komunikat do innego obiektu. Oznacza to, że może uaktywnić inny obiekt nie przerywając swojej własnej aktywności. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 25

Notacja dla oznaczania współbieżności Rodzaj interakcji synchroniczna (synchronous) Znaczenie Symbol “Normalna” proceduralna sytuacja. Nadawca

Notacja dla oznaczania współbieżności Rodzaj interakcji synchroniczna (synchronous) Znaczenie Symbol “Normalna” proceduralna sytuacja. Nadawca zawiesza działanie, dopóki odbiorca nie zwróci sterowania. Można to oznaczyć wykorzystując symbol powrotu. powrót (return) Powrót nie jest komunikatem. Oznacza zakończenie komunikatu i przekazanie sterowania do nadawcy. płaska (flat) Nadawca komunikatu przekazuje sterowanie do odbiorcy nie oczekując na odpowiedź, co oznacza, że kończy własną działalność. asynchroniczna (asynchronous) Nadawca komunikatu odbiorcy nie oczekuje na odpowiedź odbiorcy, ale też i nie kończy własnej aktywności, co oznacza, że nadal przetwarza i może wysyłać komunikaty. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 26

Przykład diagramu sekwencji ze współbieżnością : Personel bibl. : Członek bibl. Czy. Przetrzymuje [jeśli

Przykład diagramu sekwencji ze współbieżnością : Personel bibl. : Członek bibl. Czy. Przetrzymuje [jeśli przetrzymuje] email Rejestruj. Nową : Książka Rejestruj. Nowy K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 27 : Egzemplarz książki

Wyróżnianie subkolaboracji pakiet Złożona kolaboracja Wyróżnianie subkolaboracji Zamiana subkolaboracji na pakiet Opisywanie interakcji na

Wyróżnianie subkolaboracji pakiet Złożona kolaboracja Wyróżnianie subkolaboracji Zamiana subkolaboracji na pakiet Opisywanie interakcji na wyższym poziomie, ukrywanie detali, jest użyteczne, jak każda abstrakcja. Temu celowi służy wyodrębnienie subkolaboracji, a następnie zamiana jej na pakiet. Pakiet, w UML, przeznaczony jest do grupowania elementów modelu. Pakiet nie posiada własnego interfejsu, w tym sensie, że przesłanie komunikatu do pakietu, oznacza przesłanie komunikatu do obiektu wewnątrz pakietu. W UML, sparametryzowana kolaboracja jest traktowana jako wzorzec projektowy (design pattern). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 28

Law of Demeter Powszechnie stosowana reguła (Law of Demeter), określa do jakich obiektów mógłby

Law of Demeter Powszechnie stosowana reguła (Law of Demeter), określa do jakich obiektów mógłby ewentualnie wysłać komunikat obiekt O w odpowiedzi na otrzymany komunikat m: § do siebie samego, § do obiektów stanowiących argumenty metody m, § do obiektów, które tworzy w trakcie realizacji komunikatu m, § do obiektów, z którymi jest bezpośrednio powiązany. * Kontroler. Wszystkiego get. KP(p: Praca) : Kontroler. Pracy 1 1 1 Przykład złego projektowania, które nie stosuje się do zasad ww. reguły. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 29 * Praca *

Podsumowanie diagramów interakcji § Diagramy interakcji, czyli diagramy kolaboracji i sekwencji, jako główne zadanie

Podsumowanie diagramów interakcji § Diagramy interakcji, czyli diagramy kolaboracji i sekwencji, jako główne zadanie mają wspomożenie projektanta w procesie konstruowania modelu obiektowego (konretnie diagramu klas). Pomoc polega na analizie zachowania systemu w trakcie realizacji jego zadań i identyfikowaniu nowych czy też korekcie już istniejących elementów modelu, np. : klas, ich atrybutów czy metod oraz asocjacji między klasami. Struktura, opisywana przez model obiektowy, musi zapewnić możliwość realizacji zadań postawionych przed systemem. § Oba rodzaje diagramów przedstawiają bardzo podobną informację, w nieco inny sposób. § Diagramy kolaboracji, stanowiące w pewnym sensie wystąpienia fragmentu diagramu klas, lepiej przedstawiają związki między obiektami biorącymi udział w realizacji danego przypadku użycia. Łatwiej też można tu odwzorować efekty oddziaływania na pojedynczy obiekt. § Diagramy sekwencji lepiej przedstawiają zależności czasowe, bardziej niż diagramy kolaboracji nadają się do modelowania systemów czasu rzeczywistego i złożonych scenariuszy. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 9, Folia 30