DIAGRAMY UML

1. DIAGRAMY UML

2. Diagramy UML Rafał KASPRZYK

3. Przypadek użycia • Wycinek funkcjonalności, którą system musi realizować, aby spełnić wymagania • Opis zbioru ciągów akcji wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku • Zbiór scenariuszy powiązanych wspólnym celem użytkownika • Scenariusz jest to ciąg kroków opisujących interakcje między użytkownikiem, a systemem Rafał KASPRZYK

4. Zastosowanie przypadków użycia • Służą do identyfikacji wymagań funkcjonalnych • Każdy przypadek użycia powinien opisywać realizację jakiegoś celu biznesowego • Cele biznesowe opisywane są z punktu widzenia aktora używającego systemu • Umowa między dostawcą, a klientem • Ustalenie priorytetów dla wymagań funkcjonalnych • Pomagają w określeniu granic systemu • Jakie funkcje są realizowane przez system • Jakie funkcje należą do innego systemu • Przypadek użycia opisuje co system robi, ale nie określa jak to robi • Wstęp do szczegółowej analizy i projektowania • Podstawa do identyfikacji klas i obiektów • Określenie odpowiedzialności i współpracy obiektów • Definicja przepływu komunikatów między obiektami Rafał KASPRZYK

5. Relacje między przypadkami użycia • Relacja zawierania, <<include>> • Pozwala na współdzielenie funkcjonalności pomiędzy podstawowymi przypadkami użycia • Reużywalny wycinek funkcjonalności • Relacja rozszerzania, <<extend>> • Warunkowe rozszerzenie funkcjonalności podstawowego przypadku użycia osadzone w punkcie rozszerzenia • Służy do opisywania opcjonalnego przepływu zdarzeń • Pozwala na minimalizację liczby zmian wprowadzanych do podstawowego przypadku użycia • Relacja uogólnienia • Możliwości różnych implementacji tego samego przypadku użycia • Specjalizowany przypadek użycia zastępuje podstawowy przypadek użycia w jego relacjach • Oznacza szczególną implementację uogólnionego przypadku użycia Rafał KASPRZYK

6. Przykłady relacji między przypadkami użycia Rafał KASPRZYK

7. Przykład bankomatu • Diagram przypadków użycia pozwala na wizualizację • Relacji pomiędzy przypadkami użycia • Relacji pomiędzy przypadkami użycia a aktorami • Relacji pomiędzy aktorami Rafał KASPRZYK

8. Diagramy aktywności • Są grafami aktywności i przejść między nimi • Stanowią uogólnioną wersję diagramów stanów • maszyna stanu, której podstawowym zadaniem nie jest analiza stanów obiektu, ale modelowanie przetwarzania (przepływu zadań) • Stany grafu aktywności (aktywności), odpowiadają stanom wyróżnialnym w trakcie przetwarzania, a nie stanom obiektów • Aktywność może być interpretowana jako • zadanie do wykonania przez człowieka lub komputer • odpowiedzialność/operacja/metoda klasy • Przejścia między stanami raczej nie są związane z nadejściem zdarzenia, ale z zakończeniem przetwarzania specyficznego dla danej aktywności Rafał KASPRZYK

9. Zastosowanie diagramów aktywności • Diagramy aktywności są szczególnie przydatne przy modelowaniu przypływu zadań i w opisie procesów z dużą liczbą równoległych czynności • Dają możliwość opisu czynności warunkowych i współbieżnych • Proces warunkowy jest przedstawiany za pomocą rozgałęzienia (ang. branch) i scalenia (ang. marge). • Procesy współbieżne jest przedstawiany za pomocą rozwidlenia (ang. fork) i złączenia (ang. join). • Określają sposób uszeregowane działania • Opisują podstawowe reguły porządkujące czynności • Pozwalają na określenie obiektów odpowiedzialnych za wykonywanie danej czynności na wysokim poziomie abstrakcji („tory pływackie”) • W celu uszczegółowienia należy stosować diagramy interakcji • Zrozumienie procesów biznesowych • Wygodny sposób analizy przypadków użycia • Współdziałanie obiektów na wysokim poziomie abstrakcji • W celu uszczegółowienia należy stosować diagramy interakcji • Opisanie algorytmu • Sekwencyjnego • Równoległego i/lub współbieżnego (aplikacje wielowątkowe) Rafał KASPRZYK

10. Przykład obsługi zamówienia Rafał KASPRZYK

11. Klasa • Opis zbiór obiektów, które mają takie same • Atrybuty – opisują stan • Najczęściej typy proste lub biblioteczne • Nie posiadają własnych reguł biznesowych • Ich wartości są istotne dla obiektów klasy • Operacje – opisują zachowanie • Usługi oferowane przez każdy obiekt klasy • Zwykle powodują zmianę stanu obiektu • Dzielą się na zapytania i polecenia • Związki – uogólnienia, realizacje, zależności, asocjacje, … • Zachowanie klasy często zależy od zachowania innej klasy • Pozwalają na unikaniu antywzorców (np.”BLOB”) • Znaczenie • Realizuje jeden bądź więcej interfejsów • Interfejs definiuje zewnętrznie obserwowalne zachowanie takiego elementu, określając zbiór deklaracji operacji, ale nigdy sposobu implementacji Rafał KASPRZYK

12. Przykład klasy i interfejsu Rafał KASPRZYK

13. Klasy parametryzowane template<class Element> class Lista{ Element *first public: virtual dodaj(const Element& e); virtual usuń(const Element& e); } Rafał KASPRZYK

14. Klasy asocjacyjne • Klasy asocjacyjne umożliwiają dodanie dodatkowych atrybutów i operacji do asocjacji • Może istnieć tylko jedna instancja klasy asocjacyjnej między dowolnymi dwoma obiektami połączonymi asocjacją Rafał KASPRZYK

15. Asocjacja kwalifikowana • Odpowiednik tablic asocjacyjnych, map i słowników • Wskazuje sposób znajdowania powiązanych obiektów • Najczęściej powoduje konieczność implementacji powiązania w postaci mapy w kwalifikatorze z kwalifikowanym końcem Rafał KASPRZYK

16. Diagram klas dla SI uczelni Rafał KASPRZYK

17. Stereotypy analityczne dla klas • Terminator (ang. boundary) – modeluje interakcję pomiędzy aktorem a systemem • Sterowanie (ang. control) – prowadzi obliczenia, koordynację, nadzoruje transakcje i przebieg sekwencji • Encja (ang. entity) – modeluje encje biznesowe, najczęściej o charakterze trwałym (zapisywane w bazie danych) Rafał KASPRZYK

18. Diagramy sekwencji • Przedstawiają interakcje pomiędzy obiektami, przy czym największy nacisk kładą na zależności czasowe • Stosowane zawsze, gdy kolejność wywołań oraz ograniczenia czasowe są istotna • Nadają się do modelowania • Systemów czasu rzeczywistego • Przetwarzania współbieżnego • Złożonych scenariuszy • Nie prezentują związków strukturalnych między współdziałającymi obiektami • Pozwalają na modelowanie różnych typów interakcji • Synchroniczna • Asynchroniczna • Powrót Rafał KASPRZYK

19. Elementy diagramów sekwencji Rafał KASPRZYK

20. Przykład biura maklerskiego Rafał KASPRZYK

21. Diagramy współpracy • Kolejność wywołań prezentowana za pomocą numeracji • Stanowią wystąpienie fragmentu diagramu klas • Stosowane, gdy przy modelowaniu interakcji ważne jest wzajemne powiązanie obiektów • Rodzaje powiązań pomiędzy obiektami • <<field>> • <<parameter>> • <<local>> • <<global>> • … Rafał KASPRZYK

22. Przykład biura maklerskiego Rafał KASPRZYK

23. Komponenty • Fizyczna, wymienna część oprogramowania z dobrze zdefiniowanym interfejsem, wyizolowana z kontekstu i dzięki temu nadająca się do wielokrotnego wykorzystania • Każdy komponent jest luźno powiązany z innymi komponentami, najczęściej za pomocą zależności i realizacji • Rodzaje komponentów • Wdrożenia – podstawa systemu wykonywalnego • biblioteki DLL, pliki wykonywalne EXE, EJB • Procesu wytwórczego – podstawa do generacji komponentu wdrożeniowego • Wykonania – powstałe w wyniku działania systemu • Przykłady komponentów • programy wykonywalne, biblioteki, tabele, pliki, dokumenty, bazy danych itp. Rafał KASPRZYK

24. Diagramy komponentów Rafał KASPRZYK

25. Węzły • Sprzętowe składowe działającego systemu • Dzielimy na: • Procesory – reprezentują zasoby obliczeniowe • Posiadają pewną ilość pamięci i zdolność przetwarzania • Mogą wykonywać kod komponentu • Urządzenia – są interfejsem do świata zewnętrznego • Nie mają zdolności przetwarzania (np. monitor, drukarka) • Służą do modelowania infrastruktury sprzętowej (diagramy wdrożenia), pozwalając jednocześnie na zobrazowanie fizycznego rozmieszczenia (rozproszenia) komponentów na poszczególnych węzłach Rafał KASPRZYK

26. Diagramy wdrożenia Rafał KASPRZYK

27. Diagramy stanów • Są grafami stanów i przejść między nimi • Akcje są związane z przejściami i traktuje je jako procesy szybkie i nieprzerywalne • Czynności są związane ze stanami, trwają zazwyczaj dłużej, ale mogą zostać przerwane przez zdarzenie • Opisują reakcje obiektu na otrzymane komunikaty i zdarzenia zewnętrzne • Niezwykle użyteczne do modelowania obiektów reaktywnych, czyli takich których zachowanie charakteryzowane jest przez ciąg odpowiedzi na zdarzenia wywoływane w jego otoczeniu • Modelują zachowanie obiektów danej klasy w oderwaniu od reszty systemu • Wszystkie obiekty danej klasy znajdujące się w tym samym stanie reagują w jednakowy sposób na otrzymanie tego samego komunikatu lub zdarzenia Rafał KASPRZYK

28. Elementy diagramów stanów • Zdarzenia – bodziec, który może uruchomić przejście pomiędzy stanami • Wołanie – operacja(a:T) • Synchroniczne wywołanie żądania, gdzie obiekt wołający czeka na wynik • Zmiana – when(wyr.) • Ciągłe czekanie na spełnienie warunku • Sygnał – sygnał (a:T) • Asynchroniczna komunikacja jednokierunkowa • Czas – after(czas) • Uzależnione od czasu, definiowanego bezwzględnie lub względnie • Stany mogą mieć nazwy i być definiowane na trzy sposoby • Wartość atrybutów obiektów • Czas, gdy obiekt oczekuje na nadejście jakiegoś zdarzenia • Czas, w którym obiekt wykonuje jakieś czynności • Przejścia – wskazują, że obiekt przejdzie z jednego stanu do drugiego, ilekroć zajdzie określone zdarzenie i będą spełnione warunki • entry/akcja – oznacza wykonanie akcji podczas wejścia do stanu • exit/akcja – oznacza wykonanie akcji podczas wyjścia ze stanu • zdarzenie(a:T)[dozór]/akcja • Przejście zewnętrzne – wykonanie akcji exit zmiana stanu i wykonanie akcji entry • Przejście wewnętrzne – wykonanie akcji exit i entry bez zmiany stanu Rafał KASPRZYK

29. Przykład obiektu klasy ”Konto Bankowe” Rafał KASPRZYK

30. Przykład obiektu klasy ”Sesja Użytkownika” Rafał KASPRZYK