Diagram przypadków użycia: wprowadzenie

Powiemy sobie czym taki diagram jest, z czego się składa, do czego służy oraz czym jest specyfikacja przypadków użycia, która jest nieodzowna do pełnego zrozumienia funkcjonalności systemu.

Czym właściwie jest język UML?

W języku polskim UML oznacza Ujednolicony Język Modelowania (ang. Unified Modeling Language). Warto w tym miejscu zatrzymać się na chwilę na słowie „ujednolicony”, ponieważ często jest ono niesłusznie tłumaczone jako „uniwersalny”.  

Język UML powstał na przełomie lat 70. i 80. ubiegłego wieku i służy do wizualizacji, specyfikowania oraz dokumentowania składników systemów informatycznych. Ponadto umożliwia graficzne zaprezentowanie różnych punktów widzenia systemu oraz jego kontekstu w postaci diagramów. Jakie to punkty widzenia? Choćby perspektywa danych (pokazuje statyczne, niezmienne w czasie informacje), perspektywa zachowania (mówi o cyklu życia obiektów biznesowych) czy perspektywa funkcjonalna (opisuje transformację parametrów wejściowych w parametry wyjściowe).   

Jeśli natomiast chodzi o same modele tworzone w języku UML, to odwzorowują one uproszczoną rzeczywistość. Konstruowane są w bardzo konkretnym, praktycznym celu, dlatego tworząc je, zawsze skupiamy się na wybranym aspekcie modelowanego systemu.  

Diagramy UML możemy podzielić na dwa rodzaje:  

• Strukturalne, opisujące strukturę budowanego systemu i są to: diagramy klas, obiektów, pakietów, struktur złożonych oraz wdrożeniowe (komponentów i rozlokowania);  
• Behawioralne, czyli diagramy przypadków użycia, aktywności, maszyn stanów, sekwencji, komunikacji, zależności czasowych oraz sterowania interakcją. 

Diagram przypadków użycia – przykład

Tematem wiodącym artykułu są jednak diagramy przypadków użycia (DPU), więc skupmy się na nich. Aby dobrze zrozumieć temat, zbudujmy taki diagram kroku po kroku, posługując się przykładem bankomatu. 

Z definicji DPU jest diagramem, który przedstawia funkcjonalność systemu wraz z jego otoczeniem. Stosuje się go do zaprezentowania własności systemu w taki sposób jak są one widziane przez użytkowników poszczególnych funkcjonalności, a więc z zewnątrz systemu. Diagram przypadków użycia jest zazwyczaj tworzony na bardzo wczesnych etapach budowania aplikacji. W dużym uogólnieniu pokazuje do czego służy dany system oraz zawiera podstawowe elementy, które chcemy mieć zrealizowane w jego ramach. Dlatego warto rozważyć jego użycie chociażby przy projektowaniu MVP. 

Warto pamiętać: Diagramy te nie dokumentują żadnych innych interakcji pomiędzy poszczególnymi przypadkami użycia. 

DPU są bardzo fajnym sposobem na budowanie wspólnego języka pomiędzy biznesem i developerami. Po pierwsze dlatego, że możemy zbudować na nich słownik, po drugie możemy w bardzo prosty sposób dowiedzieć się, czego biznes oczekuje od systemu.  

Jeśli chodzi o modelowanie bardziej skomplikowanych rzeczy, które będą potrzebne na późniejszym etapie budowy systemu, to oczywiście stosujemy inne diagramy (na przykład diagram aktywności albo diagram klas). Niemniej diagram przypadków użycia jest najlepszym początkiem modelowania systemu.   

Z czego składa się diagram przypadków użycia?

Warto na początek wspomnieć, czym jest granica systemu i granica kontekstu. Otóż uzasadniając wymagania systemu, musimy znać jego kontekst, czyli: osoby, działające systemy, procesy, wydarzenia oraz dokumenty. 

Powyższy rysunek wyjaśnia te pojęcia. Mamy pewne „nieistotne środowisko”, do którego wchodzi wszystko, a więc różni interesariusze, inne systemy, akty prawne itp. Z tego chaosu wyłania się kontekst i granica kontekstu, czyli tylko te z wymienionych elementów, które są powiązane z tworzonym systemem. Idąc dalej mamy granicę systemu, a więc aspekty należące do środowiska systemu, które będziemy pokrywać tworzonym systemem oraz use case’y. Komunikacja pomiędzy systemem a kontekstem zachodzi za pomocą interfejsów. Dobrym przykładem przedstawienia czym jest kontekst systemu, będzie wejście w życie aktu PSD2 w powiązaniu z RODO. W konsekwencji wiele systemów musiało się zmienić pod kątem prezentowania informacji o przechowywaniu danych lub samego przechowywania danych. Systemy musiały się dostosować do nowego kontekstu. 

Szara strefa kontekstu obejmuje elementy, których nie do końca jesteśmy pewni, czy wchodzą w skład kontekstu czy też nie, ale nie musi to być rozstrzygnięte w trakcie zbierania wymagań. Natomiast jeśli chodzi o szarą strefę systemu, to ona zawsze musi zostać rozwiązana w trakcie zbierania wymagań oraz procesu inżynierii wymagań.  

Jeśli chodzi o notacje (elementy, z których składa się diagram przypadków użycia), to są to: granica systemu, która jest opcjonalna; aktorzy, czyli osoby lub inne systemy; przypadki użycia oraz różne typy powiązań pomiędzy tymi elementami modelowania. 

Wyjaśnijmy jeszcze czym jest składnia i czym jest semantyka. Składnia odpowiada za właściwą budowę diagramu – wiemy, jak diagram powinien być złożony, żebyśmy mogli go poprawnie odczytać. Natomiast za odpowiednią interpretację diagramu przypadków użycia odpowiada semantyka.

Budowa diagramu przypadków – na przykładzie bankomatu

Na przykładzie bankomatu, krok po kroku zbudujemy diagram przypadków użycia. Zaczynamy od zaznaczenia granicy systemu służącej do zdefiniowania zakresu przypadków użycia i zwizualizowanej w postaci prostokąta. Jest to element opcjonalny, ale przydatny podczas wizualizacji dużych systemów.  

Granica systemu pomaga określić kontekst systemu, który chcemy aktualnie modelować. Służy do oddzielania przypadków użycia, które są częścią modelowanego systemu od jego otoczenia, czyli od innych aktorów i systemów.

Następnie dodajemy aktorów. Aktor zawsze znajduje się poza granicami systemu i jest rolą osobową lub nieosobową, którą pełni Użytkownik w stosunku do systemu oraz przypadków użycia. Aktor reprezentuje spójne zbiory, które są odgrywane przez użytkowników przypadków użycia w czasie interakcji z tym przypadkiem. Nazwy aktorów często pokrywają się z rolami biznesowymi, ale mogą także dostarczać pewnych informacji, np. odnośnie uprawnień. Aktorów dzielimy na primary, czyli tych, którzy inicjują daną akcję oraz secondary, czyli wymaganych do tego, aby akcja mogła zostać wykonana. 

A więc na poniższej grafice zaznaczyliśmy bankomat jako naszą granicę systemu, kontekst, który będziemy modelować, aktorów, tj: klienta, konwojenta, konwojenta serwisowego, oraz bank. 

Trzeci i najważniejszy element diagramów przypadków użycia to oczywiście same przypadki użycia. Wizualnie zapisujemy je w elipsie, nadając krótkie nazwy w trybie rozkazującym. Przypadek użycia jest zbiorem scenariuszy powiązanych ze sobą wspólnym celem użytkownika. Jest graficzną reprezentacją wymagań funkcjonalnych, definiuje zachowanie systemu bez informowania o wewnętrznej strukturze i narzucania sposobu implementacji.  

Kompletny zbiór przypadków użycia, czyli wszystkie przypadki użycia, które znajdują się w ramach naszego bankomatu, definiują system jako całość: określają funkcjonalności, które są nam potrzebne. Natomiast pojedynczy przypadek określa fragment zachowania systemu, czyli określone scenariusze. 

Kolejnym elementem służącym do zbudowania przypadków użycia są typy powiązań. Pojedynczy przypadek użycia musi być powiązany pośrednio lub bezpośrednio z przynajmniej jednym aktorem.

• Do łączenia diagramów przypadków użycia z aktorami najczęściej stosuje się powiązanie poprzez asocjacje. Asocjacja łączy aktora z danym przypadkiem użycia. W naszym przypadku mamy asocjację skierowaną, która wskazuje na fakt, że element inicjujący zawsze zna element inicjowany, natomiast element inicjowany nie zna elementu inicjującego (klient wie, że może wypłacić pieniądze, ale wypłata pieniędzy nie wie, że istnieje klient). 
• Związek rozszerzenia, czyli extend, który wskazuje, że dany przypadek użycia opcjonalnie rozszerza funkcjonalność bazowego przypadku użycia (po spełnieniu określonego warunku). Na przykład przypadek użycia „wypłać pieniądze” wywołuje na ekranie bankomatu komunikat: czy chcesz wydrukować potwierdzenie? z opcją wyboru „tak” lub „nie” i odpowiednim skutkiem.  
• Związek zawierania, czyli include, który polega na rozszerzeniu funkcjonalności bazowego przypadku użycia o zachowanie innego przypadku użycia. W naszym przykładzie „wypłać pieniądze” ma związek zawierania „autoryzuj klienta”, czyli wypłata pieniędzy będzie musiała skończyć się autoryzacją. Dodatkowo do autoryzacji jest tutaj potrzebny bank jako aktor.  
• Generalizacja aktora, czyli powiązanie między elementem bardziej ogólnym (rodzicem) a elementem szczegółowym (dzieckiem), który jest w pełni zgodny z pierwszym elementem i dostarcza dodatkowych informacji. Rozumiemy to w ten sposób, że na przykład nasz aktor, który jest konwojentem serwisowym, może robić dokładnie to, co konwojent plus jeszcze swoje dodatkowe elementy (np. wykonać przegląd). 

Specyfikacja przypadków użycia

Specyfikacja przypadków użycia odgrywa kluczową rolę przy tworzeniu diagramu przypadków użycia. Jest to szczegółowy opis każdego przypadku użycia, który zawiera informacje na temat jego nazwy, opisu, aktorów biorących udział, warunków wstępnych, kroków wykonania, warunków zakończenia oraz ewentualnych rozszerzeń lub alternatywnych scenariuszy. Specyfikacja przypadków użycia pomaga w pełniejszym zrozumieniu funkcjonalności systemu i precyzyjnym określeniu, jakie zadania i akcje mogą zostać wykonane w ramach każdego przypadku użycia.

• Identyfikator: 001
• Nazwa: wypłać pieniądze
• Opis: Wypłata gotówki z bankomatu przez klienta banku
• Wyzwalacz: Włożenie karty do bankomatu
• Aktorzy: Klient
• Warunki wstępne: Klient posiada kartę; Klient ma konto w banku; Saldo konta klienta >== zadeklarowana kwota; Ilość gotówki w bankomacie >== zadeklarowana kwota 
• Rezultat: Uzyskanie zadeklarowanej kwoty w gotówce
• Warunki końcowe: Karta jest zwrócona; Saldo konta jest zaktualizowane

Dlatego warto tworzyć diagramy przypadków użycia?

Podsumowując, istnieje kilka powodów, dla których warto tworzyć diagramy przypadków użycia w procesie analizy i projektowania systemów: 

• Zrozumienie wymań użytkowników, 
• Komunikacja między zespołem a interesariuszami, 
• Zrozumienie struktury i funkcjonalności systemu, 
• Lepsza analiza i projektowanie systemu, 
• Testowanie i weryfikacja założeń systemu, 
• Przejrzystość i dokumentacja.