Specyfikacja wymagań Przypadki użycia

Proces wytwarzania oprogramowania 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

Model dziedziny problemu Przypadki użycia Analiza Model biznesowy Specyfikacja wymagań Przypadki użycia Model dziedziny problemu

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 Do powyższych kategorii należy dodać jeszcze wymagania dziedzinowe. Istnieją inne klasyfikacje wymagań: np. Użytkownika, systemu

Wymagania funkcjonalne 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

Wymagania niefunkcjonalne 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.

Specyfikacja wymagań - przykład 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 „System będzie” – oznacza, że bezwzględnie musi być zrealizowane „System powinien” – oznacza, że „jest do dyskusji”, można zmienić, odrzucić

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

Przypadek użycia - przykład 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ę

Elementy składowe Nazwa Aktor Scenariusz główny Przypadki użycia Elementy składowe Nazwa Aktor Scenariusz główny Scenariusze alternatywne

Nazwa przypadku użycia 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

Scenariusz główny i alternatywny 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 Istnieją przypadki użycia, gdzie sekcja „Rozszerzenia” również zawiera pożądany scenariusz, np. Przegladanie dokumentu w określonych widokach

Jak czytać przypadek użycia? (1) 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

Jak czytać przypadek użycia? (2) Przypadki użycia Jak czytać przypadek użycia? (2) 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ę 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

Najczęściej spotykane konstrukcje scenariuszy przypadków użycia Sekwencja Iteracja Alternatywa Specjalizacja Rozszerzenie 16

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 … 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) 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 … 19

Specjalizacja Przypadek użycia: Obsługa sprzedaży … Scenariusz główny: 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 alternatywnych (np. Płatność gotówką lub Płatność kartą) 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 20

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ć Scenariusz rozszerzenia może w pewnych sytuacjach ułatwić, przyspieszyć, a czasami nawet umożliwić realizację celu aktora Scenariusz rozszerzenia może być uruchomiony wskutek decyzji użytkownika (np. Opcjonalnie: Kupon Rabatowy) lub też w wyniku spełnienia pewnych warunków 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 rozszerzenia: 6a. Opcjonalnie: Kupon rabatowy 2a1. Kasjer przyjmuje kupon rabatowy od klienta 21

Uczestnik/Udziałowiec 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

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

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

Aktorzy i uczestnicy Uczestnik/Udziałowiec Aktor Aktor główny 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

Gdzie szukać aktorów? Kto będzie korzystał z projektowanego systemu? 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

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

Rozwiązanie Bankomat – projektowany system 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

Cechy przypadku użycia 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

Czego nie powinien zawierać p. u. 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 Technologia ulega zmianie, wymagania są bardziej stabilne Elementy interfejsu użytkownika tylko zaciemniają obraz, przypadek powinien być zwięzły i przejrzysty

Etapy tworzenia przypadków użycia Przypadki użycia Etapy tworzenia przypadków użycia Zidentyfikować aktorów i ich cele (zasada: Szerokość przed głębokością) Utworzyć główne scenariusze Zidentyfikować rozszerzenia Utworzyć scenariusze rozszerzeń

Lista aktor-cel Aktor Cel Klient Składanie zamówienia 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

Używaj prostych form gramatycznych 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

Określ jasno, kto wykonuje dany krok 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

„Stwierdzaj, że”, a nie „sprawdzaj, czy” 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

Wskazówki (4) Niepoprawnie: Nie używaj synonimów 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: 3. Użytkownik uruchamia usługę …

Nie twórz niepotrzebnych kroków 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

Niezależność od technologii i GUI 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

Szablon przypadku użycia 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

Identyfikator i źródło wymagań 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

Uczestnicy/Udziałowcy i ich interesy 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

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 Specyfikacja zakresu jest możliwa po uprzednim dokonaniu podziału przypadków użycia na grupy ze względu fragment systemu, bądź też jednostki organizacyjnej którego dotyczą

Poziomy celu Poziom celu - wyróżnia się 3 poziomy celów: Przypadki użycia Poziomy celu Poziom celu - wyróżnia się 3 poziomy celów: poziom streszczenia (biznesowy) poziom celu użytkownika poziom podfunkcji Test kawowy na określenie poziomu celu (Cockburn): Jeśli w trakcie realizacji p.u. możemy sobie zrobić przerwę, to jest to przypadek użyia na poziomie streszczenia

Poziom streszczenia (biznesowy) 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

Poziom streszczenia – przykłady (1) 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ą

Poziom streszczenia – przykłady (2) 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

Poziom celu użytkownika 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

Poziom celu użytkownika - Przykład 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

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

Poziom podfunkcji - przykłady 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.

Przypadki użycia Poziomy celu - diagram

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

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

Warunki końcowe Określają stan systemu po wykonaniu przypadku użycia 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

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

Gwarancja powodzenia Stan systemu po ukończeniu scenariusza głównego 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

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

Przypadek użycia - przykład 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:

Notacja UML – podstawowe symbole Przypadki użycia Notacja UML – podstawowe symbole Symbol Znaczenie Aktor Przypadek użycia Asocjacja – zachodzi pomiędzy aktorem a przypadkiem użycia 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 <<aktor>> Nazwa przypadku użycia <<include>> <<extend>>

Generalizacja aktorów 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

Generalizacja aktorów - przykład Przypadki użycia Generalizacja aktorów - przykład

Zależności między przypadkami użycia 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

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>> Include – strzałka od przypadku głównego

Zawieranie - przykład UC1: Złóż zamówienie Poziom: Cel Użytkownika 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 …

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>>

Rozszerzenie - przykład Przypadki użycia Rozszerzenie - przykład UC1: Edytuj dokument Scenariusz główny: 1. Użytkownik wybiera dokument do edycji 2. System otwiera wybrany dokument Użytkownik edytuje wybrany dokument 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 Extend – strzałka do przypadku głównego Scenariusze alternatywne mają charakter prywatny (dotyczą tylko przypadku w którym się znajdują), a przypadki rozszerzające mają charakter publiczny (mogą być wykorzystane przez inne przypadki użycia) 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: System sprawdza pisownie System prezentuje użytkownikowi listę błędów i propozycję poprawy Użytkownik akceptuje propozycje poprawy błędów

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

Generalizacja - przykład 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 Mogą istnieć przypadki generalizujące, które nie posiadają żadnego kroku. Całe zachowanie opisane jest wówczas w przypadkach specjalizowanych. Przypadki nie posiadające żadnego kroku, po których dziedziczą inne przypadki nazywamy abstrakcyjnymi. Powodem wyodrębniania przypadków abstrakcyjnych jest podniesienie poziomu czytelności diagramu. Na diagramie umieszcza się wówczas tylko przypadki generalizujące 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

Pakiet Forma organizacji przypadków użycia 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.

Przypadki użycia Pakiet - przykład

Instancja przypadku użycia Instancja aktora Przypadki użycia Instancja przypadku użycia Instancja aktora 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ę Przypadek użycia: Zakup napoju Aktor: Klient Scenariusz Jana 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 Instancja przypadku użycia - konkretny scenariusz Instancja aktora – konkretna osoba wykonującą instancję 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

Literatura Alistair Cockburn: Jak pisać efektywne przypadki 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