Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

PRZEDMIOT :: Przygotował: mgr inż. Rafał Kasprzyk DIAGRAMY UML.

Podobne prezentacje


Prezentacja na temat: "PRZEDMIOT :: Przygotował: mgr inż. Rafał Kasprzyk DIAGRAMY UML."— Zapis prezentacji:

1 PRZEDMIOT :: Przygotował: mgr inż. Rafał Kasprzyk DIAGRAMY UML

2 Rafał KASPRZYK2 Diagramy UML

3 Rafał KASPRZYK3 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

4 Rafał KASPRZYK4 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

5 Rafał KASPRZYK5 Relacje między przypadkami użycia Relacja zawierania, > Pozwala na współdzielenie funkcjonalności pomiędzy podstawowymi przypadkami użycia Reużywalny wycinek funkcjonalności Relacja rozszerzania, > 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

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

7 Rafał KASPRZYK7 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

8 Rafał KASPRZYK8 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

9 Rafał KASPRZYK9 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)

10 Rafał KASPRZYK10 Diagram aktywności

11 Rafał KASPRZYK11 Przykład obsługi zamówienia

12 Rafał KASPRZYK12 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

13 Rafał KASPRZYK13 Przykład klasy i interfejsu

14 Rafał KASPRZYK14 Klasy parametryzowane template class Lista{ Element *first public: virtual dodaj(const Element& e); virtual usuń(const Element& e); }

15 Rafał KASPRZYK15 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ą

16 Rafał KASPRZYK16 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

17 Rafał KASPRZYK17 Diagram klas dla SI uczelni

18 Rafał KASPRZYK18 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)

19 Rafał KASPRZYK19 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

20 Rafał KASPRZYK20 Elementy diagramów sekwencji

21 Rafał KASPRZYK21 Przykład biura maklerskiego

22 Rafał KASPRZYK22 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 > …

23 Rafał KASPRZYK23 Przykład biura maklerskiego

24 Rafał KASPRZYK24 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.

25 Rafał KASPRZYK25 Diagramy komponentów

26 Rafał KASPRZYK26 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

27 Rafał KASPRZYK27 Diagramy wdrożenia

28 Rafał KASPRZYK28 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

29 Rafał KASPRZYK29 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

30 Rafał KASPRZYK30 Przykład obiektu klasy Konto Bankowe

31 Rafał KASPRZYK31 Przykład obiektu klasy Sesja Użytkownika


Pobierz ppt "PRZEDMIOT :: Przygotował: mgr inż. Rafał Kasprzyk DIAGRAMY UML."

Podobne prezentacje


Reklamy Google