1
1
UML
UML
Diagramy przypadków
Diagramy przypadków
użycia
użycia
1
1
UML
UML
Diagramy przypadków
Diagramy przypadków
użycia
użycia
2
2
PLAN WYKŁADU
Cel stosowania przypadków użycia?
Co opisują przypadki użycia
Związki między przypadkami
użycia
Dokumentacja przypadków użycia
Przykłady poprawne
Przykłady błędów
3
3
Cel stosowania przypadków
użycia
4
4
Klasyfikacja diagramów UML 2.0
Klasyfikacja diagramów UML 2.0
1. Diagramy struktury
1. Diagramy struktury
Diagram klas (class diagram)
Diagram klas (class diagram)
Diagram komponentów (component diagram)
Diagram komponentów (component diagram)
Diagram struktur złożonych, diagram składowych, (composite
Diagram struktur złożonych, diagram składowych, (composite
structure
structure
diagram)
diagram)
Diagram wdrożenia (deployment diagram)
Diagram wdrożenia (deployment diagram)
Diagram obiektów (object diagram)
Diagram obiektów (object diagram)
Diagram pakietów (package diagram)
Diagram pakietów (package diagram)
2. Diagramy zachowania
2. Diagramy zachowania
Diagram czynności (activity diagram)
Diagram czynności (activity diagram)
Diagram przypadków użycia (use case diagram)
Diagram przypadków użycia (use case diagram)
Diagram maszyny stanów (state machine diagram)
Diagram maszyny stanów (state machine diagram)
Diagram interakcji
Diagram interakcji
- Diagram sekwencji (sequence diagram
- Diagram sekwencji (sequence diagram
- Diagram komunikacji (communication diagram)
- Diagram komunikacji (communication diagram)
- Diagram przeglądu interakcji; diagram opisu interakcji
- Diagram przeglądu interakcji; diagram opisu interakcji
(interaction overview diagram)
(interaction overview diagram)
- Diagram czasowy,diagram następstwa (timing diagram)
- Diagram czasowy,diagram następstwa (timing diagram)
5
5
Przypadki użycia
Przypadki użycia
Przypadki użycia tworzą
Przypadki użycia tworzą
specyfikację wymagań
specyfikację wymagań
.
.
Przypadek użycia jest
Przypadek użycia jest
metodą opartą na
metodą opartą na
scenariuszach
scenariuszach
, służącą do określania wymagań.
, służącą do określania wymagań.
Po raz pierwszy użyto jej w metodzie Objectory
Po raz pierwszy użyto jej w metodzie Objectory
(Jacobson i inni, 1993). Obecnie
(Jacobson i inni, 1993). Obecnie
stała się
stała się
podstawowym elementem notacji UML
podstawowym elementem notacji UML
do
do
opisywania obiektowych modeli systemu.
opisywania obiektowych modeli systemu.
W najprostszej postaci w przypadku użycia
W najprostszej postaci w przypadku użycia
definiuje się aktorów
definiuje się aktorów
biorących udział w
biorących udział w
interakcji
interakcji
i wskazuje typ tej interakcji.
i wskazuje typ tej interakcji.
6
6
Cele diagramów przypadków
Cele diagramów przypadków
użycia
użycia
Dwa podstawowe cele:
Dwa podstawowe cele:
-
-
modelowanie otoczenia systemu
modelowanie otoczenia systemu
(wyznaczenie granicy systemu i wskazanie
(wyznaczenie granicy systemu i wskazanie
aktorów, którzy wchodzą w interakcję z
aktorów, którzy wchodzą w interakcję z
systemem)
systemem)
-
-
modelowanie wymagań stawianych
modelowanie wymagań stawianych
systemowi
systemowi
(określenie, z punktu widzenia
(określenie, z punktu widzenia
otoczenia, co system powinien robić,
otoczenia, co system powinien robić,
niezależnie od tego jak ma to zrobić)
niezależnie od tego jak ma to zrobić)
7
7
Pozostałe cele stosowania przypadków
użycia
Głębsze
zrozumienie użycia
systemu będącego
przedmiotem procesu projektowania.
Zwiększenie
stopnia świadomości analityków i
projektantów
co do celów tego systemu.
Umożliwienie
interakcji zespołu
projektowego z
przyszłymi użytkownikami systemu.
Weryfikacja
poprawności i kompletności
projektu.
Ustalenie wszystkich strukturalnych i funkcjonalnych
własności systemu.
Ustalenie
składowych systemu
i związanego z nimi
planu konstrukcji systemu.
Dostarczenie podstawy do sporządzenia planu
testów systemu
.
8
8
Co opisują przypadki
użycia?
9
9
Przypadek użycia
Przypadek użycia
Przypadek użycia to
Przypadek użycia to
opis zbioru ciągów akcji
opis zbioru ciągów akcji
(i ich wariantów) wykonywanych przez system
(i ich wariantów) wykonywanych przez system
w celu dostarczenia określonemu aktorowi
w celu dostarczenia określonemu aktorowi
godnego uwagi wyniku
godnego uwagi wyniku
Przypadek użycia
Przypadek użycia
opisuje oczekiwane
opisuje oczekiwane
zachowanie
zachowanie
budowanego systemu
budowanego systemu
(podsystemu, klasy lub kooperacji), ale
(podsystemu, klasy lub kooperacji), ale
nie
nie
określa sposobu implementacji
określa sposobu implementacji
tego
tego
zachowania
zachowania
Z punktu widzenia
Z punktu widzenia
aktora przypadek użycia
aktora przypadek użycia
opisuje działanie mające dla niego jakąś
opisuje działanie mające dla niego jakąś
wartość
wartość
, na przykład:
, na przykład:
obliczenie wyniku
obliczenie wyniku
,
,
utworzenie nowego obiektu lub zmianę stanu
utworzenie nowego obiektu lub zmianę stanu
obiektu
obiektu
10
10
Związki między przypadkami
użycia
11
11
Diagram przypadków użycia
Diagram przypadków użycia
Przypadek użycia
Przypadek użycia
–
– musi mieć nazwę unikalną,
wyróżniającą go spośród innych przypadków. Jeśli jest
tylko nazwa, wtedy mówimy o ‘nazwie prostej’, lub o
‘nazwie ścieżkowej’ (nazwa jest
poprzedzona
nazwą pakietu: Nazwa_pakietu::nazwa).
Aktor
Aktor
–
– musi mieć unikalną nazwę. Można zdefiniować
zarówno ogólne rodzaje aktorów, jak i
uszczegółowienia. Aktorem może być osoba,
organizacja lub system komputerowy.
Związek
Związek
–
– pokazuje związek między przypadkiem użycia
a aktorem
dodaj odbiorce
Diagramy przypadków użycia zawierają
12
12
Aktor
Aktor
Aktor reprezentuje
Aktor reprezentuje
spójny zbiór ról
spójny zbiór ról
odgrywanych
odgrywanych
przez użytkowników przypadków użycia w czasie
przez użytkowników przypadków użycia w czasie
interakcji
interakcji
Aktorami mogą być
Aktorami mogą być
ludzie, urządzenia i inne
ludzie, urządzenia i inne
systemy
systemy
informatyczne
informatyczne
Jedna osoba może wchodzić
Jedna osoba może wchodzić
w interakcję z
w interakcję z
systemem z pozycji wielu aktorów
systemem z pozycji wielu aktorów
; np. być
; np. być
zarówno sprzedawcą, jak i klientem. I odwrotnie,
zarówno sprzedawcą, jak i klientem. I odwrotnie,
jeden aktor może odpowiadać wielu konkretnym
jeden aktor może odpowiadać wielu konkretnym
osobom.
osobom.
Aktor jest tu pierwotną przyczyną
Aktor jest tu pierwotną przyczyną
napędzającą
napędzającą
przypadki użycia. Jest on sprawcą zdarzeń
przypadki użycia. Jest on sprawcą zdarzeń
powodujących uruchomienie przypadku użycia
powodujących uruchomienie przypadku użycia
Aktorzy mogą być:
Aktorzy mogą być:
aktywni
aktywni
(inicjują przypadki
(inicjują przypadki
użycia) i
użycia) i
pasywni
pasywni
Ilustracja różnicy między pojęciem
aktora a konkretnym użytkownikiem
systemu
Kolejne kroki w konstrukcji modelu przypadków użycia
15
15
Związki między przypadkami
Związki między przypadkami
użycia
użycia
16
16
Zasady
Zasady
Semantyka
Semantyka
:
:
Diagram pokazuje
Diagram pokazuje
związki pomiędzy aktorami i
związki pomiędzy aktorami i
przypadkami użycia.
przypadkami użycia.
Notacja
Notacja
:
:
graf
graf
zawiera aktorów, przypadki użycia,
zawiera aktorów, przypadki użycia,
interfejsy i związki pomiędzy nimi,
interfejsy i związki pomiędzy nimi,
generalizację pomiędzy aktorami,
generalizację pomiędzy aktorami,
oraz generalizację i rozszerzenia
oraz generalizację i rozszerzenia
wariantów.
wariantów.
17
17
Związki
Związki
Związki występują pomiędzy:
Związki występują pomiędzy:
przypadkami użycia lub przypadkami
przypadkami użycia lub przypadkami
użycia i aktorami;
użycia i aktorami;
Rodzaje związków:
Rodzaje związków:
•
Asocjacja
Asocjacja
(association);
(association);
•
Zależności
Zależności
(dependencies)
(dependencies)
Rozszerzenie
Rozszerzenie
(extend);
(extend);
Zawieranie
Zawieranie
(include);
(include);
•
Generalizacja
Generalizacja
(generalization)
(generalization)
18
18
Asocjacje
Asocjacje
Złóż zamówienie
1
*
Sprzedawca
Związki asocjacji występują
Związki asocjacji występują
wyłącznie pomiędzy
wyłącznie pomiędzy
aktorami a
aktorami a
przypadkami użycia.
przypadkami użycia.
19
19
Zależności (dependencies)
Zależności (dependencies)
Zależność
Zależność
to taki związek pomiędzy
to taki związek pomiędzy
dwoma elementami modelowania, w
dwoma elementami modelowania, w
którym
którym
zmiana jednego
zmiana jednego
z nich,
z nich,
niezależnego,
niezależnego,
wpływa na drugi
wpływa na drugi
,
,
zależny
zależny
20
20
Związki pomiędzy przypadkami
Związki pomiędzy przypadkami
Związki zależności
Związki zależności
Zawieranie
- stereotyp <<
include
>>,
służy do uniknięcia wielokrotnego
opisywania tego samego ciągu zdarzeń
(wspólne zachowanie jest definiowane w
odrębnym przypadku użycia, który jest
następnie włączany przez bazowe
przypadki użycia.
Rozszerzanie
- stereotyp <<
extend
>>,
służy do modelowania fragmentów
przypadków użycia postrzeganych przez
użytkownika opcjonalnie (oddzielenie
działań opcjonalnych od wymaganych)
21
21
Przykłady relacji między przypadkami użycia
Przykłady relacji między przypadkami użycia
22
22
Związki pomiędzy przypadkami
Związki pomiędzy przypadkami
Uogólnienie
- potomek dziedziczy całe
zachowanie po przodku i może dodać
nowe, lub zmienić zachowanie
23
23
Związki zależności
Związki zależności
Złóż zamówienie
Data realizacji
Zamawianie
produktów
Planowanie
płatności
Zamawianie
katalogu
<<Include>>
<<Include>>
<<Include>>
<<Extend>>
1
*
Sprzedawca
24
24
Dokumentacja przypadków
użycia
25
25
Przypadki użycia - dokument
Przypadki użycia - dokument
opisu
opisu
Dla każdego przypadku użycia
Dla każdego przypadku użycia
tworzymy dokument
tworzymy dokument
opisujący przebieg zdarzeń opisany z punktu widzenia
opisujący przebieg zdarzeń opisany z punktu widzenia
aktora
aktora
Typowy opis
Typowy opis
zawiera:
zawiera:
- Jak i kiedy przypadek użycia się rozpoczyna i
- Jak i kiedy przypadek użycia się rozpoczyna i
kończy?
kończy?
- Kto uczestniczy?
- Kto uczestniczy?
- Kiedy dochodzi do interakcji z aktorami jakie obiekty
- Kiedy dochodzi do interakcji z aktorami jakie obiekty
są przekazywane?
są przekazywane?
- Typowy przebieg zdarzeń
- Typowy przebieg zdarzeń
- Alternatywne ciągi zdarzeń
- Alternatywne ciągi zdarzeń
- Przebieg zdarzeń w sytuacjach szczególnych
- Przebieg zdarzeń w sytuacjach szczególnych
(wyjątkowych)
(wyjątkowych)
Ciąg zdarzeń
Ciąg zdarzeń
można zapisać na wiele sposobów:
można zapisać na wiele sposobów:
- tekst strukturalny (nieformalny lub formalny)
- tekst strukturalny (nieformalny lub formalny)
- pseudokod
- pseudokod
26
26
Opis tekstowy przypadku użycia
Opis tekstowy przypadku użycia
„
„
Rejestracja
Rejestracja
”
”
1. Aktorzy
1. Aktorzy
:
:
* Użytkownik
* Użytkownik
* Baza użytkowników
* Baza użytkowników
2. Opis tekstowy ciągu zdarzeń
2. Opis tekstowy ciągu zdarzeń
:
:
* System wyświetla stronę główną serwisu
* System wyświetla stronę główną serwisu
* Użytkownik wybiera opcję „Rejestruj”
* Użytkownik wybiera opcję „Rejestruj”
* System wyświetla formularz rejestracji nowego
* System wyświetla formularz rejestracji nowego
użytkownika
użytkownika
*Użytkownik wprowadza unikalny login, hasło, adres email
*Użytkownik wprowadza unikalny login, hasło, adres email
oraz dane
oraz dane
adresowe
adresowe
* System sprawdza unikalność loginu
* System sprawdza unikalność loginu
Login
Login
już istnieje
już istnieje
w bazie – ponowne wyświetlenie
w bazie – ponowne wyświetlenie
formularza rejestracji z informacją o tym, że login jest
formularza rejestracji z informacją o tym, że login jest
już zarejestrowany.
już zarejestrowany.
Login
Login
nie istnieje
nie istnieje
w bazie – następny krok
w bazie – następny krok
* System zapisuje login, hasło, email, dane adresowe
* System zapisuje login, hasło, email, dane adresowe
* System informuje użytkownika o zakończeniu procesu rejestracji
* System informuje użytkownika o zakończeniu procesu rejestracji
27
27
Przykłady
Przykłady
poprawne
poprawne
28
28
Przypadek użycia
Przypadek użycia
Wypożyczanie
Wypożyczanie
Obsługa
wypożyczania
29
29
drukarnia
specjalistyczna
przekazanie manuskryptu
recenzent
wybór recenzenta
decyzja o losie publikacji
autor
ilustrator
wybór ilustratora
pracownik
kontraktowy
konsultacje
uzyskanie ISBN
centrala
kosztorysowanie
zlecenie druku
redaktor
kontrola stanu drukowania
drukarnia
30
30
Przypadki użycia- przykład
Przypadki użycia- przykład
31
31
Przykład bankomatu
Przykład bankomatu
Diagram przypadków użycia pozwala na wizualizację
Diagram przypadków użycia pozwala na wizualizację
•
Relacji pomiędzy przypadkami użycia
Relacji pomiędzy przypadkami użycia
•
Relacji pomiędzy przypadkami użycia a aktorami
Relacji pomiędzy przypadkami użycia a aktorami
•
Relacji pomiędzy aktorami
Relacji pomiędzy aktorami
32
32
Diagram przypadków użycia w Posejdonie
33
33
Przykłady błędów
Przykłady błędów
34
34
Diagram ilustrujący problemy z wyróżnianiem
Diagram ilustrujący problemy z wyróżnianiem
aktorów systemu i tworzeniem struktur
aktorów systemu i tworzeniem struktur
generalizacji-specjalizacji dla aktorów
generalizacji-specjalizacji dla aktorów
-błędna struktura
-błędna struktura
Nie jest prawdą, że każdy
pracownik „Wydziału
planowania remontów”
ma uprawnienia do
wywoływania przypadków
„Rejestrowanie usterek i
Organizowanie remontów
interwencyjnych” Takie
uprawnienia mają
wyłącznie pracownicy
„Zespołu d.s. remontów
interwencyjnych”
35
35
Diagram ilustrujący umieszczenie niezrozumiałych
Diagram ilustrujący umieszczenie niezrozumiałych
relacji między przypadkiem bazowym a przypadkiem
relacji między przypadkiem bazowym a przypadkiem
pobocznym (zła strzałka, niema ani „include” ani
pobocznym (zła strzałka, niema ani „include” ani
„extend”)
„extend”)
36
36
Diagram ilustrujący problemy z wyróżnieniem aktorów
Diagram ilustrujący problemy z wyróżnieniem aktorów
systemu i tworzeniem struktur generalizacji-specjalizacji dla
systemu i tworzeniem struktur generalizacji-specjalizacji dla
aktorów
aktorów
Uwaga
Uwaga
Przypadek użycia „Wykonywanie remontu”
Przypadek użycia „Wykonywanie remontu”
wykonywany jest
wykonywany jest
na zewnątrz systemu (błąd)
na zewnątrz systemu (błąd)
37
37
Diagram ilustrujący modelowanie
Diagram ilustrujący modelowanie
czynności realizowanych „na zewnątrz
czynności realizowanych „na zewnątrz
systemu” – tzn. bez wsparcia ze strony
systemu” – tzn. bez wsparcia ze strony
systemu w postaci przypadków użycia
systemu w postaci przypadków użycia
38
38
Literatura:
1.Cheesman J., Daniels J.,
1.Cheesman J., Daniels J.,
Komponenty w
Komponenty w
UML,
UML,
Wydawnictwa Naukowo- Techniczne
Wydawnictwa Naukowo- Techniczne
,
,
Warszawa 2004
Warszawa 2004
2.Flower M.,,
2.Flower M.,,
UML w kropelce
UML w kropelce
,
,
Wydawnictwo
Wydawnictwo
LT&P; Warszawa 2005
LT&P; Warszawa 2005