Diagram przypadków użycia jest behawioralnym typem diagramu UML i jest często używany do analizy różnych systemów. Umożliwiają one wizualizację różnych typów ról w systemie i ich interakcji z systemem. Ten samouczek dotyczący diagramów przypadków użycia obejmuje następujące tematy i pomaga w lepszym tworzeniu przypadków użycia.
- Znaczenie diagramy użycia
- Użyj obiektów diagramu przypadku
- Wytyczne diagramu przypadków użycia
- Relacje w diagramach przypadków użycia
- Jak tworzyć wykresy przypadków użytkowych ( z przykładami )
- Szablony diagramów przypadków użycia typowych scenariuszy
Znaczenie diagramy użycia
Jak wspomniano wcześniej, schematy przypadków są wykorzystywane do zebrania wymagań eksploatacyjnych systemu. W zależności od potrzeb można wykorzystać te dane na różne sposoby. Poniżej przedstawiono kilka sposobów ich wykorzystania.
- Identyfikacja funkcji i interakcja ról z nimi – Podstawowy cel stosowania diagramów przypadków.
- Aby uzyskać widok systemu na wysokim poziomie – szczególnie przydatnego podczas prezentacji dla menedżerów lub zainteresowanych stron. Możesz podkreślić role, które wchodzą w interakcję z systemem i funkcjonalność zapewnianą przez system, bez zagłębiania się w wewnętrzne funkcjonowanie systemu.
- Identyfikacja czynników wewnętrznych i zewnętrznych – Może to zabrzmieć prosto, ale w dużych, złożonych projektach system można zidentyfikować jako zewnętrzną rolę w innym przypadku zastosowania.
Użyj obiektów diagramu przypadku
Diagramy przypadków użycia składają się z 4 obiektów.
- Aktor
- Przypadek użycia
- System
- Pakiet
Obiekty te zostały dokładniej opisane poniżej.
Aktor
Aktorem na diagramu przypadku jest dowolny podmiot, który pełni rolę w danym systemie. Może to być osoba, organizacja lub zewnętrzny system i zazwyczaj rysowane jak szkielet przedstawiony poniżej.
Przypadek użycia
Przypadek użycia reprezentuje funkcję lub działanie w systemie. Jest on narysowany jako owal i nazwany za pomocą funkcji.
System
System służy do zdefiniowania zakresu przypadku użycia i jest rysowany jako prostokąt. Jest to element opcjonalny, ale przydatny podczas wizualizacji dużych systemów. Na przykład, możesz utworzyć wszystkie przypadki użycia, a następnie użyć obiektu systemowego do zdefiniowania zakresu objętego Twoim projektem. Możesz nawet użyć go do pokazania różnych obszarów objętych różnymi wydaniami.
Pakiet
Pakiet jest kolejnym opcjonalnym elementem, który jest niezwykle przydatny w złożonych wykresach. Podobne do diagramów klas, pakiety są używane do grupowania przypadków użycia. Są one narysowane jak obrazek przedstawiony poniżej.
Wytyczne diagramu przypadków użycia
Chociaż wykresy przypadków użycia mogą być wykorzystywane do różnych celów, istnieją pewne wspólne wytyczne, których należy przestrzegać podczas rysowania przypadków użycia.
Obejmują one standardy nazewnictwa, kierunki strzałek, przypadki użycia, użycie skrzynek systemowych, a także właściwe użycie relacji.
Szczegółowo omówiliśmy te wytyczne w osobnym wpisie na blogu. Więc idź dalej i sprawdź case diagram guidelines.
Relacje w diagramach przypadków użycia
Na diagramie przypadków użycia występuje pięć typów relacji. Oni są
- Związek pomiędzy aktorem a przypadkiem użycia
- Generalizacja aktora
- Rozszerzenie relacji między dwoma przypadkami użycia
- Należy uwzględnić związek między dwoma przypadkami użycia
- Generalizacja przypadku użytkowego
Wszystkie te relacje opisaliśmy w osobnym wpisie na blogu, który zawiera przykłady z obrazkami. W tym poście nie będziemy wchodzić w szczegóły, ale możesz sprawdzić relacje w diagramach przypadków użycia.
Jak utworzyć diagram przypadku użycia
Do tej pory poznałeś obiekty, relacje i wytyczne, które są krytyczne podczas rysowania diagramów przypadków użycia. Wyjaśnię różne procesy na przykładzie systemu bankowego.
Identyfikacja aktorów
Aktorzy są zewnętrznymi podmiotami, które wchodzą w interakcję z twoim systemem. Może to być osoba, inny system lub organizacja. W systemie bankowym, najbardziej oczywistym aktorem jest klient. Inni aktorzy mogą być pracownikami banku lub kasjerami, w zależności od roli, którą starasz się pokazać w przypadku użycia.
Przykładem organizacji zewnętrznej może być organ podatkowy lub bank centralny. Procesor pożyczkowy jest dobrym przykładem zewnętrznego systemu kojarzonego jako aktor.
Identyfikacja przypadków użycia
Teraz nadszedł czas, aby zidentyfikować przypadki użycia. Dobrym sposobem na to jest określenie, czego podmioty potrzebują od systemu. W systemie bankowym klient będzie musiał otworzyć rachunki, wpłacać i wypłacać środki, żądać książeczek czekowych i podobnych funkcji. Tak więc wszystkie te przypadki można uznać za przypadki użycia.
Przypadki użytkowania na najwyższym poziomie powinny zawsze zapewniać pełną funkcjonalność wymaganą przez aktora. W zależności od złożoności systemu można rozszerzyć lub dołączyć przypadki użycia.
Po zidentyfikowaniu aktorów i przypadku użycia na najwyższym poziomie masz podstawową wiedzę o systemie. Teraz możesz go precyzyjnie dostroić i dodać do niego dodatkowe warstwy szczegółów.
Poszukaj wspólnych funkcji do użycia w Uwzględnij
Poszukaj wspólnych funkcji, które mogą być ponownie wykorzystane w całym systemie. Jeśli znajdziesz dwa lub więcej przypadków użycia, które mają wspólne funkcje, możesz wyodrębnić wspólne funkcje i dodać je do osobnego przypadku użycia. Następnie można go połączyć za pomocą relacji include, aby pokazać, że jest zawsze wywoływany podczas wykonywania oryginalnego przypadku użycia. ( zobacz diagram na przykład ).
Czy możliwe jest uogólnienie aktorów i przypadków użycia
Mogą istnieć przypadki, w których podmioty są związane z podobnymi przypadkami użycia, a jednocześnie wyzwalają kilka przypadków użycia unikalnych tylko dla nich. W takich przypadkach można uogólnić aktora, aby pokazać dziedziczenie funkcji. Możesz zrobić podobną rzecz również dla przypadku użycia.
Jednym z najlepszych przykładów jest przypadek użycia “Make Payment” w systemie płatności. Można go dalej uogólniać na “Płać kartą kredytową”, “Płać gotówką”, “Płać czekiem” itp. Wszystkie one posiadają atrybuty i funkcjonalność płatności z unikalnymi dla nich scenariuszami.
Funkcje opcjonalne lub dodatkowe
Istnieją pewne funkcje, które są wyzwalane opcjonalnie. W takich przypadkach można skorzystać z rozszerzonej relacji i dołączyć do niej regułę rozszerzenia. W poniższym przykładzie systemu bankowego “Calculate Bonus” jest opcjonalny i wyzwala się tylko wtedy, gdy określony warunek jest spełniony.
Rozszerzenie nie zawsze oznacza, że jest opcjonalne. Czasami przypadek użycia połączony przez rozszerzenie może uzupełniać podstawowy przypadek użycia. Należy pamiętać, że podstawowy przypadek użycia powinien być w stanie samodzielnie wykonywać funkcję, nawet jeśli rozszerzający przypadek użycia nie jest wywoływany.
Przypadek użycia z większością scenariuszy znalezionych w wykresach przypadków użycia
Szablony diagramów przypadków użycia typowych scenariuszy
Szablon przypadku użycia dla systemu ATM
Poszliśmy dalej i stworzyliśmy szablony diagramów przypadków użycia dla niektórych typowych scenariuszy. Chociaż Twój problem lub scenariusz nie będą dokładnie takie, jak ten, możesz użyć ich jako punktu wyjścia. Sprawdź nasze szablony diagramów przypadków użycia.
Pytania dotyczące samouczka dotyczącego diagramów przypadków użycia
Staraliśmy się wyczerpująco opisać wszystko, co musisz wiedzieć o tworzeniu diagramów przypadków użycia. Jeśli masz wątpliwości co do któregoś z rozdziałów lub potrafisz wymyślić sposoby na ulepszenie tego tutorialu, daj nam znać w komentarzach.
Więcej samouczków dotyczących diagramów
- Samouczek schematu sekwencyjnego: Kompletny przewodnik z przykładami
- Samouczek modelowania procesów biznesowych (Przewodnik BPM wyjaśniający funkcje)
- Ultimate Flowchart Guide ( Kompletny samouczek Flowchart z przykładami )
