Projektowanie systemów informacyjnych

28
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 9 Model dynamiczny (1) Diagramy interakcji

description

Projektowanie systemów informacyjnych. Wykład 9. Model dynamiczny (1) Diagramy interakcji. Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa. Zagadnienia. Diagramy interakcji:. Diagramy współpracy - PowerPoint PPT Presentation

Transcript of Projektowanie systemów informacyjnych

Page 1: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 1

Projektowanie systemów informacyjnych

Ewa Stemposz, Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 9

Model dynamiczny (1) Diagramy interakcji

Page 2: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 2

Zagadnienia

Diagramy interakcji:

Diagramy współpracy Diagramy sekwencji

Generyczne diagramy interakcji:

Współbieżność na diagramach interakcji

Wyrażanie warunków Wyrażanie iteracji

Page 3: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 3

Diagramy interakcji

Diagramy interakcji, stanowiące jeden z rodzajów diagramów dynamicznych, pozwalają na utworzenie opisu interakcji obiektów systemu podczas realizacji danego zadania: np. przypadku użycia czy też 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 komunikacji 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:

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.

diagramy współpracy (kolaboracji) diagramy sekwencji.

Page 4: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 4

Diagramy współpracy; przykład

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.

Diagram współpracy pokazuje w jaki sposób system realizuje dany przypadek użycia. Współpracujące obiekty, połączone liniami nazywanymi “linkami”, tworzą rodzaj “kolektywu”, zwanego kolaboracją. Linki odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia asocjacja musi (?) istnieć na diagramie klas.

:Personelbibl.

:Członekbibl.

:Książka

:Egzemplarz książki

Można tu pokazywać teżinformacje w rodzaju:

kierunek nawigowania, nazwy linków, itp., jak na diagramie klas

pod warunkiem, że zwiększą, a nie zmniejszą czytelność diagramu.

Page 5: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 5

Interakcja na diagramach współpracy (1)

Komunikaty przedstawiane są tu w postaci etykiet strzałek rysowanych wzdłuż linków między współpracującymi obiektami.

Diagramy współpracy mogą dodatkowo pokazywać interakcje zachodzące między obiektami zaangażowanymi w realizację danego przypadku użycia. Sekwencja interakcji oznacza tu sekwencję komunikatów przesyłanych między współpracującymi obiektami.

:Personelbibl.

:Członekbibl.

:Książka

:Egzemplarz książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

4: Zaznacz wypożyczenie3: Czy wolny

komunikat wysyłanyod aktora do obiektuklasy Członek bibl.

Możliwe scenariusze: 1) nie można pożyczyć 2) można pożyczyć ale książka jest niedostępna 3) można pożyczyć, książka jest, trzeba zarejestrować wypożyczenie

Page 6: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 6

Interakcja na diagramach współpracy (2)

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.

:Personelbibl.

:Członekbibl.

:Książka

:Egzemplarz książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.2: Zaznacz wypożyczenie2.1: Czy wolny

Numeracja zagnieżdżona oznacza, że jeśli obiekt O otrzyma komunikat m o numerze np. 7.3 to ten numer będzie dołączany jako prefix do każdego komunikatu wysyłanego w trakcie realizacji komunikatu m przez O.

Page 7: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 7

Przykład interakcji komunikatów w Javie (1)

:Personelbibl.

: Książka

: EgzemplarzKsiążki

1.1: czyMożnaPożyczyć ()

1.2: pożycz (tytuł, członekBibl)

1.2.2: zaznaczWypożyczenie (członekBibl)1.2.1: czyWolny ()

1.3: zaznaczWypożyczenie (egzemplarzKsiążki)

Dla implementacji w Javie, przypadek użycia “pożycz egzemplarz książki” mógłby być zrealizowany poprzez sekwencję komunikatów, jak na poniższym diagramie (bez usuwania polskich znaków diakrytycznych). Metody klasowe będą implementowane przez metody statyczne.

:CzłonekBibl?

1: pożycz (daneOsobowe, tytuł)

Page 8: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 8

Przykład interakcji komunikatów w Javie (2)

Diagram klas, zgodny z diagramem współpracy jak na poprzedniej folii, wyglądałby, jak poniżej.

CzłonekBibl

pożycz (daneOsobowe, tytuł)czyMożnaPożyczyć ()zaznaczWypożyczenie (egzemplarzKsiążki)

Książka

pożycz (tytuł, członekBibl)

pożyczył

*0..1

EgzemplarzKsiążki

czyWolny ()zaznaczWypożyczenie (członekBibl)

1..*

Page 9: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 9

Diagramy sekwencji

:Personelbibl.

:Książka:Członek

bibl.:Egzemplarz

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

linia życia obiektuczas

aktywneżycie obiektu

Kolejność obiektów nie ma tu znaczenia, ale warto zadbać o czytelność.

Diagramy sekwencji nie pokazują linków między współpracującymi obiektami, ale można towydedukować w oparciu o zaznaczone komunikaty.

Page 10: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 10

Ilustracja przekazywania sterowania

:Personelbibl.

:Książka:Członek

bibl.:Egzemplarz

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

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

Page 11: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 11

Nakładanie ograniczeń na przepływ czasu (1)

:Sterowanie:Dzwoniący :Odbierający

podniesienie słuchawki

ton w słuchawce

wybór cyfry

łączenie

ton dzwonka uruchomienie dzwonka

podniesienie słuchawki

koniec tonu koniec dzwonienia

.

.

.

a

b

c

d

d’

{b - a < 1 sec.}

{c - b < 10 sec.}

Rozmowa jest łączona poprzez sieć{d’ - d < 5 sec.}

Główna przewaga diagramów sekwencji nad diagramami kolaboracji przejawia się w ich zdolności do graficznego prezentowania upł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.

Page 12: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 12

Nakładanie ograniczeń na przepływ czasu (2)

:Personelbibl.

:Książka:Członek

bibl.:Egzemplarz

książki

Pożycz (tytuł)

1: Czy można pożyczyć

2: Czy tytuł dostępny

2.1: Zaznacz wypożyczenie

A

C

{C-A < 5 sek.} { Zaznacz wypożyczenie - Czy tytuł dostępny < 1 sek.}

gdy interesuje nas czaswykonania komunikatu

Page 13: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 13

Wartości zwracane; tworzenie, usuwanie obiektów

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.

:Sekretariatds. nauczania

:Wykładowca

n := PobierzNazwisko

:Szef wykładowców

UtwórzNowegoSzefaWykładowców (n)

usuńX

koniec życiaobiektu

nowy obiekt pojawia się na diagramie w miejscu korespondującym z czasem jego utworzenia

Wykładowca

Szefwykładowców

diagram sekwencji

Page 14: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 14

Wartości zwracane; tworzenie, usuwanie obiektów

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 SmallTalk, 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.

:Sekretariatds. nauczania

:Szefwykładowców

[nowy]

:Wykładowca[usuwany]

2: UtwórzNowegoSzefaWykładowców (n)

1: n := PobierzNazwisko

3: usuń

Komunikaty wysyłane od aktora są tu numerowane,aby można było ustalić ich kolejność.

diagram współpracy

Page 15: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 15

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

[i = 0] x

[i = 1] y

:K

[i = 0] x

[i = 1] y

Możliwe są tu wszystkie kombinacje.Może być wysłany albo komunikat x alboy. Może też nie być wysłany żaden z nich.

ten sam punkt w czasie

dwa różne punktyw czasie

{dla interakcji synchronicznej warunki muszą się wykluczać}

Page 16: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 16

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.

:K1

7.1: [i = 0] x

7.2: [i = 1] y

:K2Linia życia dla wystąpienia klasy K2 uległarozgałęzieniu, aby podkreślić fakt, że stan obiektumoże wyglądać inaczej w zależności od tego, którykomunikat zostanie wysłany.

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.

Page 17: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 17

Generyczne diagramy interakcji (3)

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 dopóty, dopóki pozycja nie zostanie znaleziona (do momentu, 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.

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.

Page 18: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 18

Generyczne diagramy interakcji (4)

:K2 :K3

3.1: *[i := 1..2] x3.1.1: y

:K2 :K3

:K1

:K1

3.1: *[i := 1..2] x3.1.1: *[j := 1..3] y

xyxy

xyyyxyyy

sekwencjakomunikatów

Page 19: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 19

Generyczny diagram interakcji dla Javy (1)

:Personelbibl.

: Książka

: EgzemplarzKsiążki

1.1: można = czyMożnaPożyczyć ()

1.2: egzemplarzKsiążki = [można] pożycz (tytuł, członekBibl)

1.2.2: [wolny] egzemplarzKsiążki = zaznaczWypożyczenie (członekBibl)1.2.1: *[zajęty] wolny = czyWolny ()

1.3: zaznaczWypożyczenie (egzemplarzKsiążki):CzłonekBibl.

?

Dla implementacji w Javie przypadku użycia “pożycz egzemplarz książki”, generyczny diagram interakcji mógłby wyglądać nastęująco:

1: pożycz (daneOsobowe, tytuł)

Page 20: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 20

Generyczny diagram interakcji dla Javy (2)

CzłonekBibl

pożycz (daneOsobowe, tytuł)czyMożnaPożyczyć : BooleanzaznaczWypożyczenie (egzemplarzKsiążki)

Książka

pożycz (tytuł, członekBibl) : EgzemplarzKsiążki

pożyczył

*

0..1

EgzemplarzKsiążki

czyWolny : BooleanzaznaczWypożyczenie (członekBibl) : EgzemplarzKsiążki

1..*

Diagram klas, zgodny z diagramem współpracy jak na poprzednim diagramie wyglądałby, jak poniżej.

Page 21: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 21

Rodzaje interakcji

Obiekt, adresat komunikatu, musi go rozumieć, co oznacza, że klasa której jest wystąpieniem musi dostarczyć tę operację.

Konstruowanie diagramów interakcji może pomóc zarówno w identyfikowaniu operacji w klasach, jak i asocjacji między klasami, 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. Zanim wyśle odpowiedź do nadawcy komunikatu, może prowadzić obliczenia czy też wysyłać komunikaty do innych obiektów. Wysyłając komunikat do innego obiektu nadal pozostaje aktywny, 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.

Page 22: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 22

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 jednową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 jednową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.

Page 23: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 23

Modelowanie wielu wątków sterowania

Rozpoczęcie nowego wątku sterowania jest możliwe np. 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 zawieszając swojej własnej aktywności.

Page 24: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 24

Notacja dla oznaczania interakcji

Rodzaj interakcji Symbol Znaczenie

synchroniczna “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.

(synchronous)

jednostronna(flat)

Nadawca komunikatu przekazuje sterowanie do odbiorcy oraz kończy własną działalność nie oczekując na odpowiedź.

asynchroniczna(asynchronous)

Nadawca komunikatu 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.

Page 25: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 25

Przykład diagramu sekwencji ze współbieżnością

:Personelbibl.

:Członekbibl.

Czy przetrzymuje

[jeśli przetrzymuje] email

:Książka

:Egzemplarzksiążki

Rejestruj nową

Rejestruj nowy

Page 26: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 26

Wyróżnianie subkolaboracji

Złożona kolaboracja

Opisywanie interakcji na wyższym poziomie poprzez 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).

Wyróżnianie subkolaboracji Zamiana subkolaboracjina pakiet

pakiet

Page 27: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 27

Law of Demeter (Prawo zdroworozsądkowe?)

Powszechnie stosowana reguła (Law of Demeter), określa do jakich obiektów mógłby ewentualnie wysłać komunikat obiekt O w trakcie realizacji otrzymanego komunikatu 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.

KontrolerPracy

Praca

KontrolerWszystkiego

getKP(p:Praca) : KontrolerPracy

Przykład złego projektowania,które nie stosuje się np. do ostatniej z zasad ww. reguły.

*

1

1

*

1

*

Page 28: Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 9, Slajd 28

Podsumowanie diagramów interakcji

Diagramy interakcji, czyli diagramy kolaboracji i sekwencji, jako główne zadanie mają wspomożenie projektanta w procesie konstruowania modelu obiektowego (konkretnie 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.

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.

Oba rodzaje diagramów przedstawiają bardzo podobną informację, w nieco inny sposób.