UML – Unified Modeling Language (2)

1. UML – Unified Modeling Language (2) Bartosz Baliś, Na podstawie, m.in.: Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkander: UML Behavioral Modeling (tutorial) Agile modeling: http://www.agilemodeling.com

2. Modele zachowania • Diagramy interakcji (interaction diagrams) • Diagramy sekwencji (sequence) • Diagramy kolaboracji (współpracy) (collaborations) • Diagramy stanu (statecharts) • Diagramy aktywności (activity graphs)

3. Diagramy interakcji

4. Interakcje • Interakcja: zbiór komunikatów pomiędzy instancjami, tj. wywołania operacji, tworzenie i usuwanie instancji. • Komunikaty są częściowo uporządkowane w czasie • Rodzaje diagramów interakcji: • Diagramy sekwencji • Diagramy kolaboracji

5. Diagram sekwencji Diagram kolaboracji x y z 1.1: a1.2: c x y a b 1.1.1: b c z Diagramy interakcji

6. Obiekt Linia życia name : Class other bodziec name (…) Aktywacja new (…) : Class usunięcie powrót utworzenie Diagram sekwencji

7. Synchroniczna –nadawca zawiesza działanie, dopóki odbiorca nie zwróci sterowania Asynchroniczna – nadawca nie czeka na odpowiedź, kontynuuje działanie Powrót Rodzaje wiadomości

8. Rodzaje strzałek – przykład

9. Przykład – zapisywanie się studenta na seminarium

10. obiekt połączenie stereotyp bodziec window : Controller : Window window «parameter» stereotyp 1: displayPositions (window) ograniczenie 1.1.3.1 add (self) wire contents {new} 1.1 *[i := 1..n]: drawSegment (i) {new}: Line «local» line wire :Wire 1.1.2: create (r0, r1)1.1.3: display (window) stereotyp «self» ograniczenie 1.1.1a: r0 := position () 1.1.1b: r1 := position () left : Bead right : Bead Diagram kolaboracji redisplay ()

11. Kiedy używać diagramów interakcji? • Gdy chcemy pokazać interakcje pomiędzy instancjami • Aby rozpoznać interfejsy klas • Użycie diagramów sekwencji • Aby lepiej pokazać kolejność między wiadomościami • Użycie diagramów kolaboracji • Aby lepiej pokazać architekturę

12. Przykład: system rezerwacji lotu

13. Przypadek użycia: Zmień plan lotu • Aktorzy: podróżny, konto klienta db, system rezerwacji lotów • Warunki wstępne:Podróżny się zalogował • Podstawowy przebieg: • Podróżny wybiera opcję ‘zmień plan lotu’ • System pobiera konto użytkownika i plan lotu z bazy danych klientów • System prosi podróżnego, aby wybrał segment planu lotu, który chce zmienić; podróżny wybiera segment • System prosi podróżnego o nowe informacje o odlocie i przylocie; podróżny dostarcza tych informacji • Jeśli loty są dostępne, to … • … • System wyświetla podsumowanie transakcji. • Alternatywny przebieg: • Jeśli nie ma dostępnych lotów, to …

14. Podróżny Konto klienta DBMS System rezerwacji lotów :System rezerwacji zmień plan podróży pobierz konto użytk. wybierz segment zmień dane pokaż plan pokaż detale pobierz plan dostępne loty Diagram sekwencji: zmień plan lotu ::

15. 1: zmień plan lotu 2: pobierz konto użytk.3: pobierz plan : System rezerwacji 4: pokaż plan Konto klienta DBMS Podróżny 8: dostępne loty System rezerwacji lotów Diagram kolaboracji: zmień planu lotu 5: wybierz segment 7: zmień dane 6: pokaż detale

16. 4: pobierz konto użytkownika 1: zmień plan lotu : Podróżny Formularz planu lotu Protokół DBMS : Konto klienta DBMS 10: pokaż 9: wyświetl 3: pobierz konto użytk. 2: Utwórzmodyfikator Modyfikator planu lotu 5: utwórz 8: utwórz Konto Plan lotu Protokół S.R.L. : System Rezerwacji Lotów Zmień plan lotu: dokładniejszy model 7: pobierz plan 6: pobierz plan

17. Diagramy stanu

18. ON ON ON OFF Automat • Maszyna, w której wyjściowe zachowanie zależy nie tylko od aktualnych bodźców na wejściu, ale też historii poprzednich bodźców • Posiada wewnętrzny stan, który reprezentuje wczesniejsze doświadczenie ON

19. on on off off Diagram maszyny stanowej (automatu) Lamp On Lamp Off

20. stop Diagram stanów UML Stan Pseudostan początkowy Wyzwalacz (zdarzenie) Ready Przejście stop /ctr := 0 Done Stan końcowy Akcja

21. threshold time Do czego nadaje się model stanów? • Maszyna stanów nadaje się do opisu zachowania dyskretnego, sterowanego zdarzeniami (event-driven) • Nie nadaje się do modelowania zachowania ciągłego

22. Zachowanie sterowane zdarzeniami • Typy zdarzeń • interakcje: • Synchroniczne wywołanie operacji obiektu (call event) • Asynchroniczne otrzymanie sygnału (signal event) • wystąpienie chwili w czasie (time event) • upłynięcie okresu czasu • nadejście określonej daty / czasu • zmiana wartościjakiegoś bytu (change event) • Instancja zdarzenia = wystąpienie zdarzenia określonego typu • występuje w określonej chwili czasowej, nie jest rozciągła w czasie (nie trwa)

23. Przykład – wpisywanie numeru PESEL

24. Diagramy aktywności

25. Diagramy aktywności • UML-owe odpowiedniki diagramów przepływu • Model przepływ wraz z decyzjami, alternatywnymi i równoległymi ścieżkami, itp.

26. Przykład – pobierz pieniądze z bankomatu Łączenie Scalenie

27. Elementy diagramu (1) Akcja Przepływ sterowania (control flow) Start / stan początkowy Koniec całej aktywności (wszystkich przepływów) Koniec jednego przepływu w ramach aktywności Obiekt

28. Elementy diagramu (2) Rozgałęzianie i scalanie – rozgałęzianiu towarzyszy warunek Rozwidlenie i łączenie – począteki koniec współbieżnych wątków. • Różnica między scalaniem i łączeniem • Łączenie sychronizuje wchodzące przepływy – dalszy przepływ może się wykonać dopiero, gdy wszystkie wchodzące dojdą do tego punktu • Scalanie nie synchronizuje – każdy przepływ „przechodzi osobno” i akcja następująca po scalaniu może być wykonana kilka razy (dla każdego wchodzącego przepływu)

29. Elementy diagramu (3) Przepływ obiektów Przepływ obiektów – notacja skrócona Tory – podział akcji pomiędzy obiekty

30. Zastosowanie diagramów aktywności • Modelowanie przepływu sterowania / danych (obiektów) … • ... a nie modeli sterowanych zdarzeniami(maszyn stanowych) • Dobrze nadają się do modelowania skomplikowanych scenariuszy • Dobrze modelują alternatywne scenariusze

31. UML – podsumowanie

32. Pięć punktów widzenia na system • Przypadków użycia(use case view) – przypadki użycia i zachowanie systemu z punktu widzenia użytkowników końcowych, analityków i testerów • Diagramy przypadków użycia, interakcji • Projektu(design view) – klasy, interfejsy, schematy współpracy, które tworzą podstawowy słownik problemu i jego rozwiązania • Diagramy klas, obiektów, interakcji • Procesów(process view) – wątki i procesy, które składają się na współbieżne przetwarzanie w systemie, synchronizacja • Diagramy aktywności • Implementacji(implementation view) – komponenty i pliki, które składają się na fizyczną instalację (release) systemu • Diagramy komponentów • Wdrożenia(deployment view) – obejmują węzły, czyli topologię sprzętową, na której działa system • Diagramy wdrożeń