Transcript Przypadek użycia

Specyfikacja wymagań
Przypadki użycia
2
Przypadki użycia
Proces wytwarzania oprogramowania
Analiza
• Co system będzie robił (zebranie i analiza wymagań)
Projektowanie
• Jak system będzie zbudowany (opracowanie rozwiązania odpowiadającego wymaganiom)
Implementacja
• Budowa rozwiązania (kod programu, debugowanie)
Testowanie
• Czy system realizuje założone cele (opracowanie testów, walidacja)
Wdrożenie (Integracja)
• Instalacja oprogramowania w określonym środowisku
Pielęgnacja (Konserwacja)
• Modyfikowanie systemu w zależności od zmieniających się potrzeb
3
Przypadki użycia
Analiza
Model
biznesowy
Specyfikacja
wymagań
Przypadki
użycia
Model
dziedziny
problemu
4
Przypadki użycia
Specyfikacja wymagań
• Specyfikacja wymagań – opis funkcji, które
system powinien realizować oraz ograniczeń,
które powinien spełniać
• Rodzaje wymagań:
▫ Funkcjonalne
▫ Niefunkcjonalne
▫ Dziedzinowe
5
Przypadki użycia
Wymagania funkcjonalne
• Opisują co system ma robić, jakie
funkcjonalności udostępniać
• Zazwyczaj mają postać listy funkcji
realizowanych przez system
• Każda funkcja to jedno wymaganie
6
Przypadki użycia
Wymagania niefunkcjonalne
• Opisują własności i ograniczenia sytemu
• Z reguły dotyczą kwestii bezpieczeństwa,
wydajności, czasu odpowiedzi na określone
zdarzenia, itp.
• Mogą zawierać specyfikacje odnośnie języka
programowania, bazy danych, systemu
operacyjnego, itp.
7
Przypadki użycia
Specyfikacja wymagań - przykład
Wymagania funkcjonalne
…
2.1. System będzie umożliwiał przeglądanie listy wszystkich produktów
2.1.1. Lista produktów będzie podzielona na strony
2.1.2. System powinien udostępnić możliwość ustalenia liczby
produktów widocznych na stronie
2.2. System będzie umożliwiał dodawanie produktów do koszyka
…
Wymagania niefunkcjonalne
…
3.1. System będzie obsługiwał jednocześnie co najmniej 30 użytkowników
3.2. System będzie przetwarzał co najmniej 200 transakcji na minutę
3.3. Czas odpowiedzi na żądanie użytkownika nie może być dłuższy niż 1
sekunda
…
Co to jest przypadek użycia?
•
Przypadek użycia – umowa między
uczestnikami (interesariuszami) systemu
określająca sposób zachowania systemu
•
Przypadek użycia – opis zbioru ciągów akcji
wykonywanych przez system w celu dostarczenia
określonemu aktorowi godnego uwagi wyniku
•
Przypadek użycia – reprezentuje pewne odrębne
i dobrze określone zachowanie systemu lub jego
części
•
Przypadek użycia – określa, co system ma robić
•
Przypadek użycia – opisuje zachowanie systemu
z zewnętrznego punktu widzenia
8
Do czego służą przypadki użycia?
• Do zdefiniowania oczekiwanego zachowania systemu lub
jego części (specyfikacja wymagań funkcjonalnych)
• Do identyfikacji operacji systemowych
• Do opracowania różnego rodzaju testów systemu
• Do przygotowania pomocy dla użytkownika systemu
• Do „rozliczenia” pomiędzy odbiorcą a wykonawcą
systemu
9
10
Przypadki użycia
Przypadek użycia - przykład
Przypadek użycia: Zakup napoju
Aktor główny: Klient
Scenariusz główny:
1. Klient wrzuca bilon do automatu
2. Klient wybiera rodzaj napoju
3. Automat stwierdza, że wartość bilonu odpowiada cenie wybranego napoju
4. Automat wydaje napój
Scenariusze alternatywne:
*a. Awaria automatu:
*a1. Koniec przypadku użycia
3a. Cena wybranego napoju jest większa niż wartość wrzuconego bilonu:
3a1. Automat prosi o wrzucenie dodatkowego bilonu
3a2. Klient wrzuca dodatkowy bilon
3b. Cena wybranego napoju jest mniejsza niż wartości bilonu:
3b1. Automat zwraca resztę
11
Przypadki użycia
Elementy składowe
•
•
•
•
Nazwa
Aktor
Scenariusz główny
Scenariusze alternatywne
12
Przypadki użycia
Nazwa przypadku użycia
• Odzwierciedla zawartość przypadku użycia
• Zawiera wyrażenie czasownikowe
• Przykłady:
źle: Przypadek użycia 1, Wprowadź dane
dobrze: Aktualizuj dane produktu, Utwórz
konto
13
Przypadki użycia
Scenariusz główny i alternatywny
Scenariusz główny - najbardziej
prawdopodobna sekwencja kroków – ma postać
akcji wykonywanych przez aktora oraz
odpowiedzi systemu
Scenariusze alternatywne - alternatywne
sekwencje kroków wykonywane w sytuacjach
wyjątkowych
14
Przypadki użycia
Jak czytać przypadek użycia? (1)
• Przypadek użycia rozpoczyna się od wykonania pierwszego kroku
scenariusza głównego
• Kolejne kroki wykonywane są w kolejności określonej przez numerację
• Przejście do scenariusza alternatywnego następuję w momencie, gdy akcja
opisana w scenariuszu głównym nie może być zrealizowana
• Po wykonywaniu scenariusza alternatywnego następuje powrót do
scenariusza głównego do ostatnio wykonywanego kroku (chyba, że w
rozszerzeniu podano explicite krok do którego należy przejść)
• Przypadek użycia kończy się po wykonaniu ostatniego kroku scenariusza
głównego lub w momencie napotkania kroku typu „Koniec przypadku
użycia”
• Scenariusze alternatywne mogą być zagnieżdżane
15
Przypadki użycia
Jak czytać przypadek użycia? (2)
Przypadek użycia: Zakup napoju
Scenariusz główny - kolejność
wykonywania kroków zgodna
z numeracją
Rozszerzenie o charakterze
asynchronicznym – może
pojawić się w dowolnym
momencie
Rozszerzenie odnosi się do
wybranych punktów
scenariusza głównego
Aktor główny: Klient
Scenariusz główny:
1. Klient wrzuca bilon do automatu
2. Klient wybiera rodzaj napoju
3. Automat stwierdza, że wartość bilonu
odpowiada cenie wybranego napoju
4. Automat wydaje napój
Scenariusze alternatywne:
*a. Awaria automatu:
*a1. Koniec przypadku użycia
3a. Cena wybranego napoju jest większa niż wartość wrzuconego bilonu:
3a1. Automat prosi o wrzucenie dodatkowego bilonu
3a2. Klient wrzuca dodatkowy bilon
3b. Cena wybranego napoju jest mniejsza niż wartości bilonu:
3b1. Automat zwraca resztę
Najczęściej spotykane konstrukcje
scenariuszy przypadków użycia
• Sekwencja
• Iteracja
• Alternatywa
• Specjalizacja
16
• Rozszerzenie
Sekwencja
Przypadek użycia: Pokaż dane
produktu
…
Scenariusz główny:
1. Klient prosi system o pokazanie
listy dostępnych produktów
2. System wyświetla listę dostępnych
produktów
3. Klient wybiera produkt
4. System wyświetla dane produktu
(nazwa, opis, cena)
• Sekwencja – kroki wykonywane są po
kolei, zgodnie z numeracją
• Każdy z kroków jest albo żądaniem
aktora (np. Klient prosi …) albo akcją
wykonywaną przez system (np. System
wyświetla …)
...
17
Iteracja
Przypadek użycia: Przeglądaj
galerię zdjęć
…
Scenariusz główny:
1. Użytkownik wybiera galerię zdjęć
2. System wyświetla wszystkie
zdjęcia z wybranej galerii
3. Użytkownik przegląda zdjęcia z
wybranej galerii
Kroki 1-3 powtarzane są do
momentu, aż użytkownik
znajdzie pożądaną galerie
zdjęć lub określone zdjęcie
…
• Iteracja – wielokrotne wykonywanie
pewnej grupy kroków
• Iterację zwykle oznacza się w postaci
komentarza zawierającego warunek
pętli (np. Kroki 1-3 powtarzane są do
momentu aż <warunek>)
18
Alternatywa
Przypadek użycia: Aktualizuj
dane produktu
…
Scenariusz główny:
1. Administrator modyfikuje dane
produktu (nazwa, opis, cena)
2. Administrator akceptuje zmiany
3. System zapisuje zmiany
…
Scenariusz alternatywny:
2a. Administrator odrzuca zmiany:
2a1. System anuluje zmiany
…
3a. Błąd podczas zapisu danych:
3a1. System informuje o …
• Alternatywa – rozgałęzienie
przebiegu na dwie lub więcej ścieżek
o charakterze wykluczającym
• Alternatywa pojawia się wtedy, gdy
istnieje potrzeba rozdzielenia
przebiegu wskutek decyzji aktora lub
w wyniku innych czynników (wyjątki,
błędy, itp.)
• Scenariusz główny odzwierciedla
zachowanie prowadzące do
spełnienia oczekiwań aktora
(Administrator zaktualizował dane
produktu)
• Scenariusze alternatywne zwykle
opisują zachowanie w sytuacji
nadzwyczajnej (np. Błąd podczas
zapisu danych) lub też w sytuacji,
gdy aktor wybrał mniej oczekiwany
wariant (np. Administrator odrzuca
zmiany)
19
Specjalizacja
Przypadek użycia: Obsługa
sprzedaży
…
Scenariusz główny:
1. Kasjer rozpoczyna nową
sprzedaż
…
6. Klient płaci a system realizuje
płatność
…
Scenariusz alternatywny:
6a. Płatność gotówką:
2a1. Kasjer przyjmuje
gotówkę od klienta i
…
6a. Płatność kartą:
3a1. Klient wprowadza PIN
…
• Specjalizacja – uszczegółowienie
pewnego kroku scenariusza
• Specjalizacja pojawia się wtedy, gdy
istnieje kilka alternatywnych
wariantów zachowania, każdy z nich
prowadzi do osiągnięcia celu aktora i
żaden nich nie być uznany za wyraźnie
dominujący lub preferowany
• Scenariusz główny zawiera bardzo
ogólny opis zachowania (np. Klient
płaci a system realizuje płatność)
• Uszczegółowienie zachowania
umieszcza się w scenariuszach
20
alternatywnych (np. Płatność gotówką
lub Płatność kartą)
Rozszerzenie
Przypadek użycia: Obsługa
sprzedaży
…
Scenariusz główny:
• Rozszerzenie – możliwość
wykonania pewnych dodatkowych
akcji
• Rozszerzenie pojawia się wtedy, gdy
scenariusz podstawowy ma być
wzbogacony o pewne dodatkowe kroki,
które jednak nie zawsze muszą
wystąpić
1. Kasjer rozpoczyna nową
sprzedaż
…
6. Klient płaci a system realizuje • Scenariusz rozszerzenia może w
płatność
pewnych sytuacjach ułatwić,
…
przyspieszyć, a czasami nawet
Scenariusz rozszerzenia:
umożliwić realizację celu aktora
6a. Opcjonalnie: Kupon rabatowy
2a1. Kasjer przyjmuje kupon• Scenariusz rozszerzenia może być
rabatowy od klienta
uruchomiony wskutek decyzji
…
użytkownika (np. Opcjonalnie: Kupon
Rabatowy) lub też w wyniku
spełnienia pewnych warunków
21
22
Przypadki użycia
Uczestnik/Udziałowiec
Uczestnik/Udziałowiec - ktoś lub coś, co
uzyskuje korzyść w związku z realizacją
przypadku użycia. Uczestnik nie musi wchodzić
w interakcje z systemem, aby osiągnąć swój cel.
Przykłady:
 Właściciel systemu
 Instytucja nadzorcza
 Urząd skarbowy
23
Przypadki użycia
Aktor główny
Aktor główny – kontaktuje się i wchodzi w interakcje z
systemem, aby zrealizować swój cel. Aktor główny zwykle
inicjuje wykonanie przypadku użycia. Aktora nie należy
utożsamiać z konkretnymi osobami, aktor to pewna klasa
osób, które w systemie odgrywają określone role
Przykłady:




Sprzedający
Kupujący
Urzędnik
Zegar (powoduje uruchomienie jakiegoś przypadku użycia w
określonym czasie lub po upływie określonego czasu
24
Przypadki użycia
Aktor pomocniczy
Aktor pomocniczy – realizuje pewne zadania
na żądanie systemu
Przykłady:
 usługa sieciowa dostarczające określone dane,
 inny system informatyczny, z którym współpracuje
nasz system
25
Przypadki użycia
Aktorzy i uczestnicy
Uczestnik/Udziałowiec
uzyskuje korzyść z realizacji przypadku użycia
Aktor
Aktor główny
wchodzi w interakcje z systemem,
aby zrealizować swój cel
Aktor pomocniczy
realizuje pewne zadania na żądanie
systemu
26
Przypadki użycia
Gdzie szukać aktorów?
• Kto będzie korzystał z projektowanego systemu?
• Jakie inne systemy będą współpracować z
projektowanym systemem?
• Kto będzie instalował, uruchamiał, konserwował
projektowany system?
• Kto pobiera/dostarcza informacje systemowi
27
Przypadki użycia
Zadanie
Problem: Projektujemy system informatyczny dla
bankomatu. Ustalić, które elementy z poniższej listy
są uczestnikami, aktorami głównymi, aktorami
pomocniczymi lub też systemem projektowanym








Bankomat
Posiadacz karty
Karta bankomatowa
Bank
Klawiatura
Akcjonariusz banku
Drukarka
System informatyczny banku
28
Przypadki użycia
Rozwiązanie
 Bankomat – projektowany system
 Posiadacz karty – uczestnik, aktor główny
 Karta bankomatowa – nie jest aktorem ani uczestnikiem,
bo karta „nie czerpie korzyści” z realizacji przypadku użycia
 Bank – nie jest aktorem, jest to otoczenie projektowanego
systemu
 Klawiatura – nie jest aktorem, jest komponentem
projektowanego systemu
 Akcjonariusz banku – uczestnik systemu
 Drukarka – nie jest aktorem, jest komponentem
projektowanego systemu
 System informatyczny banku – aktor pomocniczy
29
Przypadki użycia
Cechy przypadku użycia
• Określa CO system (podsystem, klasa) ma robić, a nie JAK ma to robić
• Opisuje system z zewnętrznego punktu widzenia - punkt widzenia aktora, a
nie systemu
• Jest kompletny - opisuje wszystkie możliwe scenariusze zachowania
systemu w odpowiedzi na żądania jednego z uczestników systemu, zwanego
aktorem głównym
• Scenariusz główny zawiera 3 do 9 kroków
• Jest łatwy do zrozumienia, również dla osób nie posiadających
specjalistycznej wiedzy
• Zbiór przypadków użycia zawiera wszystkie możliwe sposoby na jakie
system może być używany
30
Przypadki użycia
Czego nie powinien zawierać p. u.
• Architektury systemu
• Elementów związanych z technologią
• Elementów interfejsu użytkownika
• Szczegółów realizacji
31
Etapy tworzenia przypadków
użycia
1. Zidentyfikować aktorów i ich cele (zasada:
Szerokość przed głębokością)
2. Utworzyć główne scenariusze
3. Zidentyfikować rozszerzenia
4. Utworzyć scenariusze rozszerzeń
Przypadki użycia
32
Przypadki użycia
Lista aktor-cel
Aktor
Cel
Klient
Składanie zamówienia
Sprawdzanie stanu zamówienia
Anulowanie zamówienia
Przeglądanie oferty
Pracownik
Kompletowanie zamówienia
Przygotowanie wysyłki
Wystawianie faktury
Przyjmowanie zwrotu towaru
Administrator
Zarządzanie użytkownikami
Uruchamianie systemu
33
Przypadki użycia
Wskazówki (1)
Używaj prostych form gramatycznych
Niepoprawnie:
1. W tym kroku klient wprowadza kod PIN
Poprawnie:
1. Klient wprowadza kod PIN
34
Przypadki użycia
Wskazówki (2)
Określ jasno, kto wykonuje dany krok
Niepoprawnie:
1. Do systemu wprowadzono identyfikator i hasło
Poprawnie:
1. Klient wprowadził identyfikator i hasło
35
Przypadki użycia
Wskazówki (3)
„Stwierdzaj, że”, a nie „sprawdzaj, czy”
Niepoprawnie:
1. System sprawdza, czy hasło jest poprawne.
2. Jeśli tak, wówczas system prezentuje użytkownikowi
dostępne opcje
Poprawnie:
1. System stwierdza, że hasło jest poprawne
2. System prezentuje użytkownikowi dostępne opcje
36
Przypadki użycia
Wskazówki (4)
Nie używaj synonimów
Niepoprawnie:
1. Użytkownik wprowadza dane osobowe.
2. System weryfikuje pozytywnie wprowadzone dane
3. Klient uruchamia usługę …
Poprawnie:
1. Użytkownik wprowadza dane osobowe.
2. System weryfikuje pozytywnie wprowadzone dane
3. Użytkownik uruchamia usługę …
37
Przypadki użycia
Wskazówki (6)
Nie twórz niepotrzebnych kroków
Niepoprawnie:
1. Użytkownik wprowadza imię
2. Użytkownik wprowadza nazwisko
3. Użytkownik wprowadza adres
Poprawnie:
1. Użytkownik wprowadza dane osobowe
38
Przypadki użycia
Wskazówki (7)
Niezależność od technologii i GUI
Niepoprawnie:
1. Użytkownik klika na link dane osobowe
2. System wyświetla stronę html z formularzem danych
osobowych
Poprawnie:
1. Użytkownik wybiera opcję dane osobowe
2. System prezentuje formularz danych osobowych
39
Przypadki użycia
Szablon przypadku użycia
•
•
•
•
•
•
•
•
•
•
Identyfikator
Nazwa
Źródło wymagań
Aktor główny
Uczestnicy i interesy
Zakres (projektowy)
Poziom celu
Wyzwalacz
Warunki początkowe
Warunki końcowe
▫ Minimalna gwarancja
▫ Gwarancja powodzenia
• Scenariusz główny
• Scenariusze alternatywne
40
Przypadki użycia
Identyfikator i źródło wymagań
• Identyfikator – unikalny oznaczenie dla
przypadku, np. UC 2.1, PU 3.2.2
• Źródło wymagań – skąd pochodzi przypadek
użycia (np. Specyfikacja wymagań pkt 4.2) lub
osoba, która zdefiniowała wymaganie
41
Przypadki użycia
Uczestnicy/Udziałowcy i ich interesy
• Uczestnicy/udziałowcy i ich interesy – lista
uczestników przypadku użycia oraz tego, co chcą
osiągnąć poprzez realizacje przypadku użycia
• Przykład:
Przypadek użycia: Wybierz gotówkę
Uczestnicy i interesy:
(i) Klient chce wybrać gotówkę
(ii) Właściciel bankomatu chce mieć potwierdzenie o
wykonanej transakcji
42
Przypadki użycia
Zakres
• Zakres (projektowy) – określa, czy przypadek użycia
dotyczy całego przedsiębiorstwa, jednostki
organizacyjnej, komórki, czy też systemu
informatycznego, fragmentu tego systemu
• Przykład:
Przypadek użycia: Złóż zamówienie
Zakres: Podsystem zamówienia
Przypadek użycia: Organizacja sprzedaży
Zakres: Dział sprzedaży
43
Przypadki użycia
Poziomy celu
• Poziom celu - wyróżnia się 3 poziomy celów:
▫ poziom streszczenia (biznesowy)
▫ poziom celu użytkownika
▫ poziom podfunkcji
44
Przypadki użycia
Poziom streszczenia (biznesowy)
• Obejmuje przypadki użycia, których główny cel składa się z wielu celów
cząstkowych
• Stanowią kontekst dla przypadków użycia niższych poziomów
• Charakteryzują się wieloposiedzeniowością, polegająca na tym, że cel nie
jest realizowany w jednym etapie, tj. w trakcie jednego ciągu interakcji z
systemem
• Czas trwania streszczających przypadków użycia jest o wiele dłuższy niż czas
trwania przypadków użycia na poziomie celu użytkownika – może wynosić
od kilku godzin do nawet kilku lat
• Przypadki użycia na poziomie streszczenia opisują zazwyczaj pewien proces
biznesowy, w którym występuje wielu aktorów
45
Przypadki użycia
Poziom streszczenia – przykłady (1)
• Sklep internetowy
Przypadek użycia: Sprzedaż towarów
Poziom celu: Streszczenie
Komentarz: Na przypadek użycia składają się następujące
przypadki niższego poziomu:
(i) Składanie zamówienia, realizowane przez klienta,
(ii) Przygotowanie towarów, realizowane przez dział
zamówień i polegające na zebraniu wszystkich
zamawianych produktów
(iii) Wysyłka produktów, realizowane z kolei przez dział
wysyłek we współpracy z firmą kurierską lub pocztą
46
Przypadki użycia
Poziom streszczenia – przykłady (2)
• System aukcyjny
Przypadek użycia: Zakup przedmiotu na
licytacji
Poziom celu: Streszczenie
Komentarz: Internauta licytuje zazwyczaj wiele razy zanim uda
mu się wygrać licytację. Proces ten jest rozłożony w czasie. Każda z
takich licytacji stanowi jedno posiedzenie
47
Przypadki użycia
Poziom celu użytkownika
• Przypadki użycia na tym poziomie opisują sekwencje
czynności, po wykonaniu której użytkownik systemu uzyska
jakąś korzyść
• Tego typu przypadki użycia charakteryzują się
jednoposiedzeniowością - użytkownik systemu po wykonaniu
ciągu interakcji z system osiąga jakąś korzyść, przy czym
żaden z pośrednich kroków nie stanowi dla użytkownika
wartości samej w sobie
• Poziom celu użytkownika jest tym poziomem, na którym
powinien się skupić analityk, bowiem tego typu przypadki
dostarczają najwięcej wartościowych informacji dla
projektanta systemu
• Grupa przypadków na poziomie celu użytkownika jest
najliczniejsza w całym projekcie systemu
48
Przypadki użycia
Poziom celu użytkownika - Przykład
• Bankomat
Przypadek użycia: Wybierz gotówkę
Poziom Celu: Użytkownika
Komentarz: Wybierając gotówkę z bankomatu wykonywane
są m.in. takie czynności jak: Weryfikacja karty, Weryfikacja
PIN-u, itd. Żadna z tych czynności nie jest celem użytkownika
- jest jedynie środkiem do realizacji celu głównego, jakim jest
wypłata gotówki. Nietrudno zauważyć, że przypadek użycia
Wypłać gotówkę spełnia warunek jednego posiedzenia: nie
można bowiem włożyć karty, wprowadzić PIN i zgłosić się za
kilka dni po odbiór gotówki
49
Przypadki użycia
Poziom podfunkcji
• Obejmuje przypadki użycia, które same w sobie nie
stanowią wartości dla użytkownika – są jedynie
środkiem do uzyskania celu
• Liczba kroków w tego typu przypadkach jest zazwyczaj
nieduża
• Wyodrębnienie podfunkcji w postaci nowego przypadku
użycia zwykle ma na celu uproszczenie przypadku
głównego lub wykorzystanie wyodrębnionego
zachowania w kilku innych przypadkach użycia
50
Przypadki użycia
Poziom podfunkcji - przykłady
• Loguj się do systemu
• Wyślij powiadomienie
Komentarz: Tego typu operacje nie stanowią wartości samej w
sobie. Logujemy się do sytemu, aby np. sprawdzić saldo konta – i to
stanowi pewną wartość dla użytkownika.
51
Przypadki użycia
Poziomy celu - diagram
52
Przypadki użycia
Biznesowe a systemowe przypadki
użycia
• Biznesowy przypadek użycia:
▫ Zakres - zakresem jest całe przedsiębiorstwo lub jego dział,
komórka, etc.
▫ Poziom celu - cel przypadku użycia jest realizowany
wieloposiedzeniowo
• Systemowy przypadek użycia:
▫ Zakres - zakresem jest system lub jego cześć (podsystem, moduł,
etc.)
▫ Poziom celu - aktor realizuje swój cel w trakcie jednej sesji
53
Przypadki użycia
Warunki początkowe
• Określają stan systemu w momencie rozpoczęcia przypadku użycia
• Spełnienie warunków początkowych leży w gestii systemu
• System nie pozwoli na rozpoczęcie przypadku użycia, jeśli warunek
początkowy nie jest spełniony
• Najczęściej w tej sekcji umieszcza się informację o wykonaniu
jakiegoś innego przypadku, od którego zależy możliwość wykonanie
danego przypadku użycia
• Przykład:
Warunek początkowy: Użytkownik jest
zalogowany
54
Przypadki użycia
Warunki końcowe
• Określają stan systemu po wykonaniu
przypadku użycia
• Istnieją dwa rodzaje warunków
końcowych:
▫ Minimalna gwarancja
▫ Gwarancja powodzenia
55
Przypadki użycia
Minimalna gwarancja
• Stan systemu po ukończeniu przypadku użycia, niezależnie od
realizowanego scenariusza
• Przykłady:
Minimalna gwarancja: Dziennik systemowy zawiera wpis o
dokonanej transakcji, pozwalający odtworzyć przebieg
zdarzeń
Minimalna gwarancja: Brak zmian w systemie
56
Przypadki użycia
Gwarancja powodzenia
• Stan systemu po ukończeniu scenariusza głównego
• W tej sekcji należy opisać w jaki sposób zrealizowano cele wszystkich
uczestników
• Pomocne w tej kwestii może być pytanie: Co sprawi, że uczestnik będzie
niezadowolony po ukończeniu głównego scenariusza? Lista zaprzeczeń
odpowiedzi na powyższe pytanie stanowi gwarancje powodzenia
• Przykład:
Przypadek użycia: Wypłać gotówkę
Gwarancją powodzenia:
(i) Bankomat wydał gotówkę w kwocie wnioskowanej
przez klienta
(ii) Stan konta klienta został pomniejszony o kwotę
równą wnioskowanej kwocie
57
Przypadki użycia
Wyzwalacz
• Określa zdarzenie, które powoduje rozpoczęcie przypadku użycia
• Czasami wyzwalacz poprzedza pierwszy krok przypadku użycia,
czasami jest pierwszym krokiem
• Przykłady:
Wyzwalacz: Klient wkłada kartę do bankomatu
Wyzwalacz: Recepcjonistka odbiera telefon od klienta w
sprawie reklamacji
58
Przypadki użycia
Przypadek użycia - przykład
Nazwa: Wybierz gotówkę
Aktor główny: Klient
Uczestnicy i interesy:
Klient chce wybrać gotówkę
Właściciel bankomatu chce mieć potwierdzenie o wykonanej transakcji
Zakres: Bankomat
Poziom: Cel użytkownika
Warunki początkowe: Bankomat jest sprawny i zawiera gotówkę
Minimalna gwarancja: Dziennik systemowy zawiera informacje, pozwalające
odtworzyć sekwencje wszystkich działań
Gwarancja powodzenia:
Bankomat wydał gotówkę w kwocie wnioskowanej przez klienta,
Stan konta klienta został pomniejszony o kwotę równą wnioskowanej kwocie
Wyzwalacz: Klient wkłada kartę do bankomatu
Główny scenariusz:
…
Rozszerzenia:
…
59
Przypadki użycia
Notacja UML – podstawowe symbole
Symbol
Znaczenie
<<aktor>>
Nazwa
przypadku
użycia
Aktor
Przypadek użycia
Asocjacja – zachodzi pomiędzy aktorem a
przypadkiem użycia
<<include>>
<<extend>>
Zawieranie – zachodzi pomiędzy
przypadkami użycia
Rozszerzenie – zachodzi pomiędzy
przypadkami użycia
Generalizacja – zachodzi pomiędzy
przypadkami użycia lub pomiędzy aktorami
60
Przypadki użycia
Generalizacja aktorów
• Generalizacja - relacja miedzy
aktorem ogólniejszym a
specjalizowanym
• Aktor specjalizowany może
wykonać wszystkie przypadki
użycia aktora ogólniejszego,
ale nie odwrotnie
61
Przypadki użycia
Generalizacja aktorów - przykład
62
Przypadki użycia
Zależności między przypadkami użycia
• Notacja UML dopuszcza 3 rodzaje zależności
między przypadkami użycia:
▫ zawieranie
▫ rozszerzenie
▫ generalizacja/specjalizacja
63
Przypadki użycia
Zawieranie
• Związek zawierania oznacza, że przypadek bazowy wywołuje inny przypadek użycia
(zwany przypadkiem zawieranym ) w określonym miejscu
• Związku zawierania używa się w sytuacji, gdy pewna sekwencja kroków jest wspólna
dla kilku przypadków użycia, bądź też wtedy, gdy przypadek użycia jest bardzo
złożony
• W przypadku bazowym i przypadku zawieranym występują ci sami aktorzy
• Związek zawierania oznacza się stereotypem <<include>>
64
Przypadki użycia
Zawieranie - przykład
UC1: Złóż zamówienie
Poziom: Cel Użytkownika
Scenariusz główny:
1. Użytkownik przegląda produkty UC3.
Przeglądaj produkty
2. Klient dodaje produkt do koszyka
3. System umieszcza produkt w koszyku i
podlicza zawartość koszyka
…
UC3: Przeglądaj produkty
Poziom: Cel użytkownika
Scenariusz główny:
1. Klient prosi system o pokazanie listy produktów
2. System wyświetla listę produktów
3. Klient wybiera jeden produkt
4. System wyświetla szczegółowe dane o
produkcie
…
65
Przypadki użycia
Rozszerzenie
• Związek rozszerzenia oznacza, że przypadek bazowy może w określonym kroku
wywołać inny przypadek, zwany przypadkiem rozszerzającym
• Związku rozszerzenia używa się do modelowania sytuacji, gdzie istnieje pewien
typowy scenariusz oraz dodatkowe czynności, które mają charakter opcjonalny
• Rozszerzenie zostało pomyślane jako sposób na dodanie nowej funkcjonalności, bez
ingerencji w pierwotną treść przypadku użycia
• W przypadku bazowym i rozszerzeniu występują ci sami aktorzy
• Związek rozszerzenia oznacza się stereotypem <<extend>>
66
Przypadki użycia
Rozszerzenie - przykład
UC1: Edytuj dokument
Scenariusz główny:
1. Użytkownik wybiera dokument do edycji
2. System otwiera wybrany dokument
3. Użytkownik edytuje wybrany dokument
4. Użytkownik prosi system o zapisanie dokumentu
Scenariusze alternatywne:
2a. Dokument nie może być otwarty:
2a1. …
Punkty rozszerzenia:
3a Opcja sprawdzanie pisowni: UC3. Sprawdź pisownie
3b Opcja synonimy: UC4. Znajdź synonim
UC3: Sprawdź pisownię
Warunek początkowy: Dokument, dla którego ma być
sprawdzana pisownia jest otwarty (UC1 Edytuj dokument)
Wyzwalacz: Użytkownik wybrał opcję sprawdzania
pisowni
Scenariusz główny:
1. System sprawdza pisownie
2. System prezentuje użytkownikowi listę błędów i
propozycję poprawy
3. Użytkownik akceptuje propozycje poprawy błędów
67
Przypadki użycia
Generalizacja
• Oznacza sytuacje, kiedy jeden przypadek użycia jest specjalizowaną wersją innego
przypadku użycia
• Przypadek specjalizowany dziedziczy całą sekwencje kroków po przypadku bazowym
• Kroki odziedziczone po przypadku bazowym mogą być zmieniane, usuwane; można
również dodawać nowe kroki
• W przypadku specjalizowanym mogą występować inni aktorzy niż w przypadku
bazowym
68
Przypadki użycia
Generalizacja - przykład
UC1: Rezerwacja pokoju
Scenariusz główny:
1. Rezerwujący przegląda ofertę i wybiera pokój
2. Rezerwujący prosi system o rezerwacje
wybranego pokoju
3. System rezerwuje wybrany pokój
4. System wystawia potwierdzenie rezerwacji
UC1.1: Rezerwacja przez WWW
Scenariusz główny:
1.1. Internauta prosi system o pokazanie listy pokoi
1.2. System wyświetla listę pokoi
1.3. Internauta wybiera pokój
1.4. System pokazuje szczegółowe dane pokoju
2-4 Tak jak w przypadku generalizującym
UC1.2: Rezerwacja telefoniczna
Scenariusz główny:
1.1. Recepcjonistka odbiera telefon od klienta…
1.2. Recepcjonistka prosi system o wyszukanie
pokoju spełniającego kryteria klienta
1.3. System wyszykuje pokój spełniający kryteria
2-4 Tak jak w przypadku generalizującym
69
Przypadki użycia
Pakiet
• Forma organizacji przypadków użycia
• Obejmuje przypadki użycia logicznie powiązane
ze sobą, tzn. posiadające tego samego aktora,
dotyczące tego samego problemu (biznesowego
przypadku użycia), itp.
70
Przypadki użycia
Pakiet - przykład
71
Instancja przypadku użycia
Instancja aktora
Przypadek użycia: Zakup
napoju
Aktor: Klient
Przypadek użycia: Zakup napoju
Aktor główny: Klient
Główny scenariusz:
1. Klient wrzuca bilon do automatu
2. Klient wybiera rodzaj napoju
3. Automat stwierdza, że wartość bilonu odpowiada cenie
wybranego napoju
4. Automat wydaje napój
Scenariusze alternatywne:
*a. Awaria automatu:
*a1. Koniec przypadku użycia
3a. Cena wybranego napoju jest większa niż wartość
wrzuconego bilonu:
3a1. Automat prosi o wrzucenie dodatkowego bilonu
3a2. Klient wrzuca dodatkowy bilon
3b. Cena wybranego napoju jest mniejsza niż wartości bilonu:
3b1. Automat zwraca resztę
Scenariusz Jana
Instancja przypadku użycia konkretny scenariusz
Instancja aktora – konkretna
osoba wykonującą instancję
przypadku użycia
Przypadki użycia
1. Jan wrzuca bilon do automatu przy ul. Szewskiej
2. Jan wybiera rodzaj napoju
*a. Awaria automatu przy ul. Szewskiej:
*a1. Koniec przypadku użycia
Scenariusz Anny
1. Anna wrzuca bilon do automatu przy ul. Szewskiej
2. Anna wybiera rodzaj napoju
3. Automat przy ul. Szewskiej stwierdza, że wartość bilonu
odpowiada cenie wybranego napoju
4. Automat przy ul. Szewskiej wydaje napój
72
Przypadki użycia
Literatura
• Alistair Cockburn: Jak pisać efektywne przypadki
• S. Adolph, P. Bramble, A Cockburn, A Pols: Patterns for
effective use cases
• http://mediawiki.ilab.pl/index.php/Inżynie
ria_oprogramowania
• http://www.wirfs-brock.com/Resources.html