Diagram przypadków użycia

Budowanie rozwiązań informatycznych poprzedza określenie potrzeb. Potrzeby te, zwane wymaganiami, pozwalają określić, jaki ma być system i jakie funkcje ma realizować. Wymagania w pierwszej fazie ich zbierania są zazwyczaj zapisywane słownie. Przy zastosowaniu języka UML mogą zostać również przedstawione w formie graficznej. Możliwość graficznego odwzorowania wymagań funkcjonalnych stawianych systemowi jest jedną z największych zalet języka UML. W tym wpisie przedstawimy technikę umożliwiającą modelowanie otoczenia systemu i stawianych mu wymagań.

Diagram przypadków użycia – definicja i zastosowanie

Diagram przypadków użycia (ang. use case diagram) to graficzna reprezentacja funkcjonalności systemu wraz z jego otoczeniem. Diagramy te pozwalają na prezentację właściwości systemu z perspektywy użytkownika oraz zobrazowanie usług widocznych z zewnątrz systemu.

Diagram przypadków użycia – notacja i semantyka

Budowanie rozwiązań informatycznych poprzedza określenie potrzeb. Potrzeby te, zwane wymaganiami, pozwalają określić, jaki ma być system i jakie funkcje ma realizować. Wymagania w pierwszej fazie ich zbierania są zazwyczaj zapisywane słownie. Przy zastosowaniu języka UML mogą zostać również przedstawione w formie graficznej. Możliwość graficznego odwzorowania wymagań funkcjonalnych stawianych systemowi jest jedną z największych zalet języka UML. W tym wpisie przedstawimy technikę umożliwiającą modelowanie otoczenia systemu i stawianych mu wymagań.

Diagram przypadków użycia – definicja i zastosowanie

Diagram przypadków użycia (ang. use case diagram) to graficzna reprezentacja funkcjonalności systemu wraz z jego otoczeniem. Diagramy te pozwalają na prezentację funkcji systemu z perspektywy użytkownika oraz zobrazowanie usług widocznych z zewnątrz systemu.

Diagram przypadków użycia – notacja i semantyka

Mimo że diagram przypadków użycia składa się z kilku elementów, odgrywa kluczową rolę w procesie projektowania systemu. Opisuje wymagania funkcjonalne, którym system musi sprostać, oraz otoczenie, w którym się znajduje. Diagram ten jest agregatem funkcji i usług wykonywanych przez system. Oprócz specyfikacji, pozwala na:

Identyfikację funkcjonalności

• Umożliwia jasne określenie granic systemu poprzez wizualizację interakcji między systemem a jego otoczeniem (aktorami).
• Pomaga w identyfikacji kluczowych funkcji systemu, które bezpośrednio odpowiadają na potrzeby użytkowników.
• Ułatwia priorytetyzację funkcjonalności poprzez analizę częstotliwości i znaczenia poszczególnych przypadków użycia.
• Wspomaga wykrywanie brakujących lub nadmiarowych funkcjonalności na wczesnym etapie projektowania.

Weryfikację postępów w modelowaniu i implementacji

• Stanowi punkt odniesienia dla zespołu projektowego, umożliwiając śledzenie postępów w implementacji poszczególnych funkcjonalności.
• Pozwala na łatwe porównanie aktualnego stanu systemu z planowanymi funkcjonalnościami.
• Umożliwia iteracyjne rozwijanie systemu poprzez stopniowe dodawanie i uszczegóławianie przypadków użycia.
• Wspomaga proces testowania, dostarczając podstawy do tworzenia scenariuszy testowych opartych na przypadkach użycia.

Wspieranie komunikacji między uczestnikami projektu

• Dostarcza wspólnego języka dla różnych interesariuszy projektu (klientów, analityków, programistów, testerów).
• Ułatwia zrozumienie systemu przez osoby nietechniczne dzięki graficznej reprezentacji funkcjonalności.
• Stanowi podstawę do dyskusji i negocjacji zakresu projektu między klientem a zespołem deweloperskim.
• Pomaga w identyfikacji potencjalnych problemów i nieporozumień na wczesnym etapie projektu.
• Wspiera dokumentację projektu, dostarczając przejrzysty obraz funkcjonalności systemu.

Przypadek użycia

Przypadek użycia (ang. use case) to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika. Jest graficzną reprezentacją wymagań funkcjonalnych. Definiuje zachowanie systemu bez informowania o jego wewnętrznej strukturze i narzucania sposobu implementacji.

Każdy przypadek użycia można opisać za pomocą następujących cech:

1. Nazwa
2. Opis
3. Przepływ zdarzeń (scenariusze)
4. Zależności i relacje
5. Diagramy aktywności
6. Wymagania specjalne
7. Warunki wstępne
8. Warunki końcowe

Scenariusze są jedną z najważniejszych cech przypadku użycia. Wskazują one sekwencję kolejno wykonywanych czynności służących do zrealizowania funkcjonalności zobrazowanej przez dany przypadek użycia.

Aktor

Aktor (ang. actor) reprezentuje rolę, którą pełni użytkownik w stosunku do systemu oraz przypadków użycia. Aktor może być człowiekiem, urządzeniem lub innym systemem. Istotne jest, by pełnił określoną funkcję wobec systemu i przypadku użycia, którego używa.

Cechy aktora:

• Nie jest częścią systemu
• Reprezentuje rolę, w którą może wcielić się użytkownik
• Może reprezentować człowieka, urządzenie bądź inny system
• Może aktywnie wymieniać informacje z systemem
• Może dostarczać informacje

Szczególną uwagę należy zwrócić na fakt, iż aktor zawsze reprezentuje otoczenie systemu (nie jest częścią systemu) i musi być w interakcji chociaż
z jednym przypadkiem użycia.

Połączenia w diagramie przypadków użycia

Asocjacja

Do łączenia przypadków użycia z aktorami najczęściej stosuje się powiązanie poprzez asocjację.

Asocjacja wskazuje na to, że aktor korzysta z danej funkcji lub w chodzi w interakcję z systemem. Zazwyczaj odbiera jakieś dane lub dostarcza.

Przykładowy opis przypadku użycia: Rezerwacja samochodu

Aktor główny

Klient

Warunki wstępne

1. Klient jest zarejestrowany w systemie.
2. Klient jest zalogowany na swoje konto.

Warunki końcowe

1. Rezerwacja samochodu jest potwierdzona i zapisana w systemie.
2. Klient otrzymuje potwierdzenie rezerwacji.

Scenariusz główny

1. Klient wybiera opcję „Zarezerwuj samochód” w systemie.
2. System wyświetla formularz rezerwacji.
3. Klient wprowadza wymagane dane:
   • Data i godzina rozpoczęcia rezerwacji
   • Data i godzina zakończenia rezerwacji
   • Preferowana lokalizacja odbioru
   • Preferowana lokalizacja zwrotu
4. System sprawdza dostępność samochodów (include: Sprawdź Dostępność).
5. System wyświetla listę dostępnych samochodów wraz z cenami.
6. Klient wybiera konkretny samochód.
7. System wyświetla podsumowanie rezerwacji.
8. System weryfikuje dane klienta (include: Zweryfikuj Dane Klienta).
9. System oferuje opcję dodatkowego ubezpieczenia (extend: Wybierz Ubezpieczenie).
10. Klient potwierdza rezerwację.
11. System przekierowuje klienta do systemu płatności (include: Dokonaj Płatności).
12. Klient dokonuje płatności.
13. System potwierdza płatność.
14. System zapisuje rezerwację.
15. System generuje i wysyła potwierdzenie rezerwacji do klienta.

Scenariusze alternatywne

4a. Brak dostępnych samochodów:

1. System informuje klienta o braku dostępności.
2. System proponuje alternatywne daty lub lokalizacje.
3. Klient może zmodyfikować kryteria rezerwacji lub zakończyć proces.

8a. Weryfikacja danych klienta nie powiodła się:

1. System informuje klienta o problemie.
2. System prosi o aktualizację danych.
3. Klient aktualizuje dane lub kończy proces rezerwacji.

12a. Płatność nie powiodła się:

1. System informuje klienta o niepowodzeniu płatności.
2. System oferuje możliwość wyboru innej metody płatności.
3. Klient wybiera inną metodę płatności lub kończy proces rezerwacji.

Do opisania scenariuszy przypadków użycia o wiele lepiej sprawdzają się diagramy aktywności. 

Związki strukturalne: zawieranie i rozszerzenie

W diagramach przypadków użycia UML występują dwa główne typy związków strukturalnych: zawieranie (include) i rozszerzenie (extend). Oba te związki służą do modelowania relacji między przypadkami użycia, ale mają różne zastosowania i interpretacje.

Związek zawierania (ang. include):

• Reprezentuje obowiązkowe włączenie zachowania jednego przypadku użycia w inny.
• Stosowany, gdy część funkcjonalności jest współdzielona przez wiele przypadków użycia.
• Grot strzałki zawsze skierowany jest w stronę zawieranego przypadku użycia.
• Oznaczany stereotypem <<include>>.
• Czytany jako: „Przypadek użycia bazowy zawiera przypadek użycia zawarty”.

Związek rozszerzenia (ang. extend):

• Wskazuje, że dany przypadek użycia opcjonalnie rozszerza funkcjonalność bazowego przypadku użycia.
• Stosowany, gdy mamy do czynienia z wariantowym lub opcjonalnym zachowaniem.
• Funkcjonalność bazowego przypadku użycia jest rozszerzana po spełnieniu określonego warunku.
• Grot strzałki musi być skierowany w kierunku bazowego przypadku użycia.
• Oznaczany stereotypem <<extend>>.
• Czytany jako: „Przypadek użycia rozszerzający może rozszerzyć przypadek użycia bazowy”.

Rys. 4 Związki rozszerzenia i zawierania

Przedstawiony rysunek ilustruje oba typy związków na dwóch poziomach: ogólnym i konkretnym przykładzie.

Górna część rysunku (ogólna):

• „Przypadek użycia bazowy” jest centralnym elementem.
• Z lewej strony „Rozszerzający przypadek użycia” jest połączony z bazowym relacją <<extend>>.
• Z prawej strony „Zawierany przypadek użycia” jest połączony z bazowym relacją <<include>>.

Dolna część rysunku (konkretny przykład):

• „Rezerwacja samochodu” jest centralnym (bazowym) przypadkiem użycia.
• „Doubezpieczenie pojazdu” jest połączone z „Rezerwacją samochodu” relacją <<extend>>, co oznacza, że jest to opcjonalna funkcjonalność, która może, ale nie musi być wykonana podczas rezerwacji.
• „Weryfikacja dostępności samochodu” jest połączona z „Rezerwacją samochodu” relacją <<include>>, co oznacza, że jest to obowiązkowa część procesu rezerwacji.

Jak czytać ten przykład:

1. Podstawowy proces to „Rezerwacja samochodu”.
2. Każda rezerwacja samochodu musi zawierać (include) weryfikację dostępności samochodu. Jest to nieodłączna część procesu rezerwacji.
3. Podczas rezerwacji samochodu klient może (ale nie musi) zdecydować się na doubezpieczenie pojazdu. Jest to opcjonalne rozszerzenie (extend) procesu rezerwacji.

Takie modelowanie pozwala na czytelne przedstawienie zarówno obowiązkowych, jak i opcjonalnych elementów procesu, co jest kluczowe dla zrozumienia pełnej funkcjonalności systemu rezerwacji samochodów.

Należy także pamiętać, że każdy przypadek użycia musi być przyporządkowany minimum jednemu aktorowi, a każdy aktor przyporządkowany jest minimum jednemu przypadkowi użycia. Jeżeli przypadki użycia są połączone związkami zawierania lub rozszerzenia, to bazowy przypadek użycia staje się punktem łączącym aktora z danym przypadkiem użycia. od tej reguły są wyjątki. Do wyjątków należeć będą funkcje wewnętrzne aplikacji, które nie są widoczne z punktu widzenia otoczenia systemu.

Podsumowanie

Zrozumienie i prawidłowe stosowanie diagramów przypadków użycia, wraz z umiejętnością interpretacji związków include i extend, jest kluczowe dla efektywnego modelowania systemów i komunikacji w zespołach projektowych. Diagramy te stanowią pomost między wymaganiami biznesowymi a techniczną implementacją, zapewniając jasny obraz funkcjonalności systemu dla wszystkich zaangażowanych stron.

Pozostałe diagramy UML:

• diagram przypadków użycia,
• diagram klas,
• diagram aktywności,
• diagram sekwencji,
• diagram komponentów,
• diagram wdrożenia.