PRZEDMIOT:
:
Przygotował:
mgr inż. Rafał Kasprzyk
DIAGRAMY UML
Rafał KASPRZYK
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
11
Przykład obsługi zamówienia
Rafał KASPRZYK
12
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
13
Przykład klasy i interfejsu
Rafał KASPRZYK
14
Klasy parametryzowane
template<class Element> class Lista{
Element *first
public:
virtual dodaj(const Element& e);
virtual usuń(const Element& e);
}
Rafał KASPRZYK
15
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
16
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
17
Diagram klas dla SI uczelni
Rafał KASPRZYK
18
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
19
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
20
Elementy diagramów sekwencji
Rafał KASPRZYK
21
Przykład biura maklerskiego
Rafał KASPRZYK
22
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
23
Przykład biura maklerskiego
Rafał KASPRZYK
24
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
25
Diagramy komponentów
Rafał KASPRZYK
26
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
27
Diagramy wdrożenia
Rafał KASPRZYK
28
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
29
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
30
Przykład obiektu klasy ”
Konto
Bankowe
”
Rafał KASPRZYK
31
Przykład obiektu klasy ”
Sesja
Użytkownika
”