Diagram przypadków użycia

Podstawą i punktem wyjściowym do tworzenia systemu informatycznego są potrzeby jego przyszłych użytkowników. Potrzeby zwane również wymaganiami określają to, jaki ma być system i jakie powinien pełnić funkcje. Dzięki zastosowaniu języka UML wymagania funkcjonalności mogą być zapisane w formie graficznej za pomocą diagramów przypadków użycia. Możliwość prezentacji graficznej wymagań dotyczących funkcjonalności jest łatwym i zrozumiałym sposobem komunikacji między osobami zaangażowanymi w proces budowy systemu.

Istnieją dwa rodzaje diagramów przypadków użycia. Pierwszy z nich dotyczy biznesowych przypadków użycia i koncentruje się na procesach biznesowych. Natomiast drugi skupia się wokół systemowych przypadków użycia i odnosi się do oprogramowania. Post ten został napisany bardziej w kontekście systemowych przypadków użycia – biznesowe przypadki użycia będą szerzej omówione przy okazji tematu modelowania biznesowego.

Diagramy przypadków użycia są metodą dokumentowania wymagań przyszłych użytkowników systemu. Dzięki nim możliwe jest określenie funkcjonalności tworzonego systemu oraz sposobu komunikowania się z nim użytkowników, czyli jego interakcji z otoczeniem. Na diagramie przypadków użycia przedstawione są przypadki użycia systemu oraz powiązani z nimi aktorzy. Dzięki temu możliwe jest odczytanie tego, jakie role pełnia aktorzy wobec systemu - jakie są właściwości systemu widziane po stronie użytkownika, oraz jakie usługi świadczy system wobec aktorów. Przypadki użycia są pewnego rodzaju zagregowanymi usługami – mogą być dekomponowane na mniejsze i bardziej szczegółowe zadania/czynności. Diagramy przypadków użycia są zazwyczaj doprecyzowywane przez diagramy czynności lub też diagramy sekwencji.

Oprócz celu podstawowego, którym jest identyfikacja i dokumentacja wymagań, diagramy przypadków użycia realizują również cele dodatkowe. Umożliwiają m.in. analizę dziedziny problemowej badanego obszaru funkcjonalności (jak np. identyfikacja użytkowników) oraz stanowią podstawę do opracowania projektu przyszłego systemu. Pełnią także rolę interfejsu komunikacyjnego pomiędzy interesariuszami – aktorami, inwestorami, twórcami, itp. Diagramy przypadków użycia stanowią też umowne ramy funkcjonalności budowanego systemu, a także są podstawą do opracowywania testów na dalszych etapach rozwoju oprogramowania. Nie opisują rozwiązań technicznych prezentowanych funkcjonalności – wymieniają jedynie jakie usługi są świadczone przez system na rzecz jego aktorów.

Głównymi elementami notacji stosowanymi na tego typu diagramie są przypadki użycia, aktorzy i związki.

Przypadek użycia

Przypadek użycia (use case) jest graficzną formą reprezentacji wymagań funkcjonalnych. Określa zakres funkcjonalności, którą użytkownik uruchamia podczas korzystania z systemu. Nie informuje o wewnętrznej strukturze i nie narzuca sposobu implementacji. Przypadek użycia jest zgodny z wymaganiami i określa ciąg akcji i ich wariantów, które system wykonuje za pośrednictwem interakcji z aktorami. Jest to kompleksowe działanie, które jak już wspomniano, może być dekomponowane w dalszych etapach projektowania systemu, np. na diagramach czynności. Funkcjonalność reprezentowana przez przypadek użycia musi mieć istotne znaczenie jako całość z punktu widzenia powiązanego z nią aktora.

Każdy przypadek użycia powinien być opisany przez scenariusze – czyli ciągi kolejno wykonywanych czynności, służących do realizowania funkcjonalności danego przypadku użycia. Scenariusze zawierają:

• podstawowy przebieg zdarzeń, czyli bazowy i oczekiwany zestaw czynności, oraz
• alternatywne przebiegi zdarzeń, czyli możliwe warianty zestawu czynności uzależnione od pewnych z góry określonych warunków, wyjątków lub błędów.

Każdy scenariusz może być opisany za pomocą diagramów czynności w dalszych etapach opracowywania systemu.

Graficznie przypadki użycia reprezentowane są za zwyczaj za pomocą elipsy z nazwą wewnątrz niej. Nazwa przypadku użycia wyrażana jest w postaci wyrażenia w trybie rozkazującym (np. Rezerwuj miejsce) lub wyrażenia z rzeczownikiem odczasownikowym (np. Rezerwowanie miejsca). Poniżej możliwe warianty notacji.

Ponadto, możliwe jest stosowanie nazwy ścieżkowej. W tej sytuacji nazwę przypadku poprzedza nazwa pakietu, w którym dany przypadek użycia się znajduje.

Aktor

Aktor jest kategorią pojęciową reprezentującą użytkowników/klientów systemu. Aktor określa zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. Rozróżniamy dwie kategorie aktorów. Pierwsza z nich reprezentuje aktorów osobowych, czyli np. osobę, jednostkę organizacyjną firmy, zespół, dział. Druga kategoria to aktorzy nieosobowi. Zaliczamy do nich systemy zewnętrzne, bazy danych, różnego typu urządzenia, a także czas determinujący rozpoczęcie bądź zakończenie jakiegoś procesu. Różne rodzaje aktorów mogą być stereotypowane graficznie lub słownie, np. <<system>>. Nazwa aktora  jest wyrażana rzeczownikiem w liczbie pojedynczej. Odzwierciedla najczęściej stanowisko pracownika lub rolę w organizacji, czy też projekcie. Aktor może wchodzić w interakcję z wieloma (ale co najmniej jednym) przypadkami użycia. Podobnie jeden przypadek użycia może być w interakcji z wieloma aktorami. Aktor może uruchomić i realizować funkcjonalność przypadku użycia, a także dostarczać i odbierać od niego dane. Należy pamiętać, że aktor jest otoczeniem systemu – nie jego częścią. 

W celu określenia zakresu funkcjonalności budowanego systemu można wykorzystać granicę obszaru zastosowań. Graficznie jest to rozwiązane za pomocą prostokąta grupującego przypadki użycia z jednej dziedziny przedmiotowej. Aktorzy komunikujący się z systemem są umieszczani poza tym prostokątem. 

Poza tym, istnieje również pojęcie diagramu kontekstowego, który przysłania funkcjonalność systemu i prezentuje go jako całość na zasadzie „czarnej skrzynki”. Diagram kontekstowy stanowi zestawienie aktorów będących w interakcji z systemem. Na diagramie nie są widoczne poszczególne przypadki użycia – aktorzy są połączeni z prostokątem reprezentującym system lub podsystem. Stosowanie tego typu diagramu może okazać się pomocne w identyfikacji zbioru aktorów przed sporządzeniem szczegółowego diagramu przypadków użycia.

Związek 

Związek łączy aktora z przypadkiem użycia oraz przypadki użycia z innymi przypadkami użycia. Występują cztery kategorie związków:

• asocjacja,
• zależność,
• generalizacja,
• realizacja.

Asocjacja wskazuje na komunikację pomiędzy aktorem i przypadkiem użycia. Chociaż domyślnie, komunikacja ta jest dwukierunkowa, może wskazywać także kierunek nawigacji – kiedy ważne jest pokazanie tego, kto lub co inicjuje interakcję. W tym przypadku element inicjujący zawsze zna element inicjowany, natomiast element inicjowany nie zna elementu inicjującego. Na diagramie przypadków użycia asocjacje nie posiadają nazw. Nie jest to konieczne, ponieważ ważne jest tutaj jedynie pokazanie odpowiedzialności za wywołanie określonych funkcjonalności systemu oraz ewentualnie odebranie wyników jego pracy. Przy asocjacji dopuszczalne jest stosowanie liczności. Liczność określa ile razy może być wywołana określona funkcjonalność w odniesieniu do jednego aktora.

Zależność jest rodzajem związku, w którym zmiana jednego elementu wpływa na drugi, będący od niego zależny. Na diagramie przypadków użycia wykorzystane mogą być dwa rodzaje związków zależności:

• zawieranie,
• rozszerzanie.

Zależność zawierania stereotypowana słowem <<include>> dotyczy relacji pomiędzy przypadkiem zawierającym (podstawowym), a przypadkiem zawieranym. Zawierany przypadek użycia jest uruchamiany wyłącznie przy odwołaniu się do zawierającego przypadku użycia. Inaczej mówiąc, podstawowy przypadek użycia rozszerza swoją funkcjonalność o inny przypadek użycia. Uruchomienie podstawowego, zawierającego przypadku użycia wiąże się z zainicjowaniem zawieranego przypadku użycia. Zawierany przypadek użycia jest wykonywany obligatoryjnie. Po zakończeniu się realizacji zawieranego przypadku użycia, następuje uruchomienie funkcjonalności zawierającego przypadku użycia. Jeden zawierany przypadek użycia może być wykorzystywany przez inne zawierające przypadki użycia. Stanowi zakres funkcjonalności wielokrotnego użytku, co przyczynia się do redukcji złożoności modelu.

Zależność rozszerzania <<extend>> również opisuje relację pomiędzy dwoma przypadkami użycia. W tym wypadku, przypadek podstawowy nazwany jest rozszerzanym przypadkiem użycia. Przypadek uzupełniający go jest nazywany rozszerzającym przypadkiem użycia. Funkcjonalność reprezentowana przez rozszerzający przypadek użycia może być opcjonalnie wykorzystana przy realizacji rozszerzanego przypadku użycia. Następuje to po spełnieniu określonych warunków. Warunki te zdefiniowane są jako punkty rozszerzania (extension points). Punkty rozszerzania umieszczane są zazwyczaj w podstawowym (rozszerzanym) przypadku użycia. Rzadziej występują w formie notatki połączonej z zależnością rozszerzania. Po zakończeniu wykonywania funkcjonalności rozszerzającego przypadku użycia, kontynuowana jest realizacja rozszerzanego przypadku użycia. W odróżnieniu do zależności zawierania, zależność rozszerzania skierowana jest od przypadku rozszerzającego do rozszerzanego.

Związek generalizacji może być stosowany zarówno w przypadku aktorów, jak i przypadków użycia. Opisuje dziedziczenie cech elementu ogólnego przez element szczegółowy, który może te cechy rozszerzać. Element szczegółowy może zastąpić element ogólny. Zależność generalizacji skierowana jest od elementu szczegółowego do elementu ogólnego.  

Realizacja to związek pomiędzy dwoma elementami modelu, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego. W odniesieniu do przypadków użycia pozwala modelować relacje występujące pomiędzy ogólnym, funkcjonalnym opisem systemu w postaci diagramu przypadków użycia a jego wdrożeniem. W ten sposób diagram przypadków użycia zostaje jawnie powiązany z innymi diagramami (statycznymi i dynamicznymi), które zawierają bardziej szczegółowe informacje dotyczące implementacji. Modele opisujące wdrożenie przypadku użycia określane są mianem współdziałań (cooperations). Współdziałania można łączyć w ciągi coraz bardziej szczegółowych za pomocą zależności ze stereotypem <<refine>>, która wskazuje, że element docelowy jest bardziej szczegółowy niż element źródłowy.

Diagram przypadków użycia pozwala na określenie funkcjonalności systemu i jego otoczenia. Wskazuje co system robi i jaką funkcjonalność realizuje. Dokumentuje wymagania dotyczące funkcjonalności i użytkowników systemu, co stanowi dobry punkt wyjścia do kolejnych etapów analizy i projektowania systemu.

Źródła