1 / 30

DIAGRAMY UML

DIAGRAMY UML. Diagramy UML. 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

tambre
Download Presentation

DIAGRAMY UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related