Diagram przypadków użycia uznawany jest za najważniejszy diagram w procesie projektowania systemu. Jego “siłą” jest to, że przedstawia funkcjonalności systemu wraz z jego otoczeniem, a na projektowany system patrzy “z zewnątrz”, od strony funkcjonalności dostępnych dla użytkownika.
Diagram Przypadków Użycia pozwala zidentyfikować wymagania, jakim system musi sprostać i otoczenie, w jakim się znajduje. W bardzo czytelny sposób umożliwia też pokazanie funkcjonalności przewidywanych dla poszczególnych użytkowników.
Diagram ten składa się dosłownie z kilku elementów, z których najważniejsze to: aktorzy, przypadki użycia i ich wzajemne relacje.
PRZYPADEK UŻYCIA (ang. use case)
„Specyfikacja ciągu akcji i ich wariantów, które system (lub inna jednostka) może wykonać poprzez interakcję z aktorami tego systemu”
(definicja OMG).
Przypadek użycia, inaczej mówiąc, to zbiór scenariuszy związanych ze sobą wspólnym celem użytkownika.
Za jego pomocą można graficznie przedstawić wymagania funkcjonalne.
Zwróćcie uwagę, że przypadek użycia opisuje KTO i CO, nie JAK – nie wskazuje zachowań przepływów procesu.
Pojedynczy przypadek użycia jest kompleksowym działaniem realizowanym w systemie w konsekwencji określonej aktywności użytkownika systemu.
PU musi łączyć się z co najmniej jednym aktorem (wyjątkiem jest PU włączany relacją “include”). Wystąpienie przypadku użycia powinno zawierać warunek wstępny.
Ogromnym błędem, niestety często występującym na diagramach PU, jest próba sekwencyjnego umieszczenia PU, co wskazywać by miało np. na czas wykonywania konkretnych działań lub powiązania ich w jakieś logiczne procesy. A to tylko lista funkcji, spróbujcie spojrzeć na diagram PU jak na wykaz funkcjonalności, np. rzut oka na menu systemu czy wykaz czynności dostępnych w jakiejś jego rozbudowanej części.
OPIS PRZYPADKU UŻYCIA
Jak życie uczy, niestety nie wystarczy wykazać przypadków użycia na diagramie 🙂 Sama prezentacja funkcjonalności w formie graficznej jest bardzo przydatna, jednak nie przenosi wszystkich niezbędnych informacji o danym PU. Do przedstawienia szczegółów funkcjonalności służy tzw. Opis Przypadków Użycia.
Należy pamiętać, iż absolutnie każdy wykazywany na diagramie przypadek użycia powinien być opisany!
Opis przypadków użycia, powinien zawierać przynajmniej:
- Nazwa PU
- Numer PU (unikatowy, umożliwiający odwoływanie się do niego w dokumentacji)
- Skrótowy opis
- Warunki wstępne
- Scenariusze (przepływy)
- Warunki końcowe
- Zależności i relacje
- Wymagania specjalne
Warto też dodać interfejsy (wskazać, w którym widoku dostępny jest PU), aktorów (role zaangażowane w realizację PU) oraz “uwagi” – czyli najważniejsze dane, niezawierające się w żadnym innym polu.
Działanie wynikające z PU powinno dostarczać wartości dodanej z punktu widzenia użytkownika systemu. Sam scenariusz pojedynczego przypadku użycia nie powinien przekraczać 10-20 kroków. Jeśli w scenariuszu wystąpi mniejsza liczba kroków, można się zastanowić, czy przypadkiem nie podeszliśmy do tematu zbyt szczegółowo. Natomiast przy zbyt dużej liczbie kroków zdecydowanie warto rozważyć rozbicie “dużego PU” na kilka mniejszych.
AKTOR (ang. actor)
Aktor to zbiór ról odgrywanych przez uczestników PU w czasie interakcji z tym przypadkiem użycia. Może być osobowy lub nieosobowy (np. podsystemy, bazy danych, urządzenia, czas).
Aktorzy nie prezentują indywidualnych obiektów ze świata rzeczywistego, lecz role pełnione przez te obiekty. Czyli przykładowo: nie mówimy o konkretnej osobie, która ma wykonywać zadania w systemie, tylko o stanowisku zaangażowanym w realizacje procesu.
Każdy aktor powinien być powiązany z przynajmniej jednym przypadkiem użycia.
Generalizacja (uogólnienie)
Uogólnienie umożliwia powiązanie klasyfikatora ogólnego ze specjalizowanym. Stosowane jest zazwyczaj przy prezentacji uogólnień i specjalizacji aktorów.
Po ludzku tłumacząc 😉 Jeśli jest aktor, który może coś zrobić w Systemie, i jest też inny aktor, który może zrobić to samo plus jedną lub kilka rzeczy dodatkowo, to warto rozważyć zastosowanie generalizacji. Zwiększamy w ten sposób czytelność diagramu i na prawdę, uwierzcie, ułatwiamy sobie późniejsze aktualizowanie dokumentacji 😉
Asocjacja – związek między aktorem a przypadkiem użycia
Asocjacja–prezentuje powiązanie aktora z przypadkiem użycia.
Wskazuje na dwukierunkową komunikację między aktorem a PU. Używana, by wskazać, którzy aktorzy są uprawnienia do wykorzystania danych usług systemowych.
Asocjacja skierowana–wskazuje na element pasywny i aktywny (inicjujący komunikacje)
Liczebność (ang. multiplicity)
Możliwe jest wskazanie liczebności w relacji aktor – przypadek użycia. Liczebności te oznaczają:
- od strony aktora: wskazanie liczby aktorów inicjujących przypadek użycia
- od strony przypadków użycia –wskazanie liczby przypadków użycia, w które aktor może być zaangażowany.
Związki między przypadkami użycia
Przypadki użycia może łączyć związek rozszerzenia (extend) lub zawierania (include).
Zawieranie (ang. include)
„Zależność to taki związek między dwoma elementami modelowania, w którym zmiana jednego z nich (niezależnego) wpływa na drugi (zależny)” (OMG)
Związek zawierania (include) ma charakter obligatoryjny. Oznacza to, że zawierany przypadek użycia jest wymagany do realizacji przypadku zawierającego. Jego użycie nakłada obowiązek wykonania wskazanego PU.
Zawierany przypadek użycia nie jest wykonywany samodzielnie, lecz wyłącznie przy odwołaniu się do większego, zawierającego PU.
Należy go czytać w następujący sposób: jeśli wystąpi przypadek “zawierający”, to NA PEWNO będzie wykonany przypadek zawierany.
Przypadku „includowanego” nie wiąże się z aktorem relacją asocjacji.
Include stosuje się gdy:
- istnieje możliwość wydzielenia w formie zawierania użycia spójnej, wspólnej dla kilku innych przypadków użycia funkcjonalności;
- interakcje aktor-system wyrażone w dokumentacji scenariusza tego PU są bardzo liczne.
Ale uwaga na include! Mimo, że wygląda bardzo “ładnie”, to użyty niewłaściwie lub w nadmiarze może utrudnić prawidłowy odczyt diagramu przypadków użycia! Dlatego pamiętaj! jeśli nie jesteś pewien poprawności relacji INCLUDE, nie twórz jej!
Rozszerzenie (ang. extend)
Związek rozszerzenia jest opcjonalny. Funkcjonalność rozszerzająca może, ale nie musi być włączona do rozszerzanego przypadku użycia. Tworzenie zależności rozszerzania jest uzasadnione o ile funkcjonalność reprezentowana przez rozszerzający przypadek użycia ma zostać uzupełniona o kilka dodatkowych kroków.
Dodatkowa funkcjonalność (rozszerzająca) nie jest wykonywana automatycznie.
Miejsce rozszerzania (ang. extension point)
Warunek lub zestaw warunków umożliwiający przejście do przypadku rozszerzającego, opisywany jest za pomocą tzw “extension point” – miejsca rozszerzenia. Extension point mogą być wykazane bezpośrednio w PU
lub mogą być opisane w formie notatek, dołączonych do właściwej asocjacji.
GRANICA SYSTEMU (ang. BOUNDARY, SYSTEM)
Z mojego punktu widzenia granica systemu jest na tyle istotnym zagadnieniem, że należy się jej oddzielny wpis. To właśnie od właściwie zidentyfikowanych i określonych granic często zależy sukces analizy, a w efekcie – całego projektu.
Granicę systemu zaznacza się na diagramie PU za pomocą prostokąta. Określa on przypadki użycia, które wchodzą w zakres systemu lub tego jego fragmentu, który aktualnie jest analizowany.
Pamiętajcie, że aktorzy nigdy nie wchodzą w zakres systemu.