Szybki przewodnik po modelowaniu przypadków użycia

Modelowanie przypadków użyciajest przydatnym narzędziem do uchwycenia wymagań. Zapewnia graficzną reprezentację wymagań systemu oprogramowania.

Z publikacją Ivara Jacobsonaksiążki z 1991 roku Inżynieria oprogramowania zorientowanego obiektowo, podejście oparte na przypadkach użycia, modelowanie przypadków użycia skutecznie stało się praktyczną techniką analizy”. Dziś Jacobson nadal promuje to podejście do analizy systemów i zaktualizował je do Use Case 2.0, które jest oficjalnie jednym z 14 typów diagramów UML.

Ponieważ model przypadku użycia jest prosty w koncepcji i wyglądzie, stosunkowo łatwo jest omówić jego poprawność z personelem nietechnicznym (takim jak klienci).

Przypadek użycia nie jest procedurą, procesem ani funkcją.

Elementy diagramu przypadków użycia

Elementy diagramu przypadków użyciato aktorzy (podmioty zewnętrzne) oraz sam przypadek użycia. Ogólnie rzecz biorąc, przypadek użycia to jednostka funkcjonalna (wymaganie) lub usługa w systemie.

Aktor

Aktor aktorjest każdą jednostką zewnętrzną w stosunku do systemu projektowego, niezależnie od tego, czy jest to osoba, czy inny podmiot nie-ludzki. Użytkownik systemu jest typowym przykładem aktora. Inne typy aktorów obejmują systemy oprogramowania, które są integrowane z obecnym systemem (np. system baz danych), zewnętrzny sprzęt, taki jak czujnik itp.

Istnieją dwa notacje w specyfikacji UML:

Używanie stickmana dla aktorów jest bardziej ekspresyjne, ale może prowadzić do zamieszania, jeśli aktor nie jest faktycznie osobą, lecz maszyną lub urządzeniem zewnętrznym. Symbol prostokąta jest standardowym notacją UMLdla klasy.

Aktor to rola, a nie rzeczywista osoba

Aktor reprezentuje rolę podmiotu, który wchodzi w interakcję z obecnym systemem, a nie instancję.Notacja aktora wskazuje, że podmiot jest klasą, a nie instancją (tj. rzeczywistym użytkownikiem Johnem lub Mary). Powód, dla którego aktor jest typem klasy, polega na tym, że nie jest to sam aktor, lecz rola, którą odgrywa.

Na przykład aktor może reprezentować klientów banku, zamiast określać osobnego aktora dla każdego klienta. Podobnie, może być inny aktor reprezentujący menedżera banku. Co ciekawe, w rzeczywistym świecie menedżer banku może być również klientem tego samego banku. Innymi słowy, ta sama osoba odgrywa rolę zarówno klienta, jak i menedżera.

Aktorzy główni vs aktorzy pomocniczy

Aktor głównyprzypadku użycia to interesariusz, który wymaga, aby system świadczył swoje usługi. Ma cel związany z systemem – cel, który może być zaspokojony przez działanie systemu. Aktor główny jest zazwyczaj, ale nie zawsze, aktorem, który uruchamia przypadek użycia.

Aktor pomocniczy jest używany przez system, ale nie wchodzi w interakcję z systemem samodzielnie. Innymi słowy, aktorzy pomocniczy nie inicjują żadnych przypadków użycia.

Przypadki użycia są zazwyczaj inicjowane przez aktorów głównych. System korzysta z aktora pomocniczego, takiego jak baza danych, poprzez zestaw przypadków użycia. Związek między przypadkami użycia a uczestnikami reprezentuje komunikację dwukierunkową.

Zatem dla każdego przypadku użycia inicjowanego przez aktora głównego, połączony przypadek użycia musi być odpowiedziany. Podobnie, dla każdego związku między aktorem pomocniczym a przypadkiem użycia, komunikacja zaczyna się od przypadku użycia, a aktor pomocniczy powinien odpowiedzieć na inicjację.

Przypadek użycia

Przypadki użyciareprezentują funkcje (zwykle wymagania), które mają być wdrożone przez system. Szczegóły przypadku użycia, z wyjątkiem jego unikalnej nazwy, nie są intuicyjnie wyrażone w diagramie; Szczegóły te są podane w opisie przypadku użycia.

Przypadki użycia są zazwyczaj inicjowane przez kluczowych aktorów. System korzysta z bazy danych i innych uczestników pomocniczych poprzez zestaw przypadków użycia.

Związek między przypadkami użycia a aktorami reprezentuje komunikację dwukierunkową. Dlatego dla każdego przypadku użycia inicjowanego przez głównego aktora, na ten ostatni musi być odpowiedziane. Podobnie, dla każdego związku między aktorem pomocniczym a przypadkiem użycia, komunikacja zaczyna się od przypadku użycia, a aktor pomocniczy powinien odpowiedzieć na inicjację.

Granica systemu

Granica systemu definiuje system interesujący w odniesieniu do otaczającego go świata.

Przykład diagramu przypadków użycia: System rezerwacji lotów

Przypadki użycia definiują interakcje między zewnętrznymi aktorami a systemem w celu osiągnięcia określonych celów. Diagram przypadków użycia zawiera cztery główne komponenty

W diagramie przypadków użycia systemu rezerwacji biletów system jest reprezentowany przez prostokąty zawierające wiele różnych przypadków użycia. Aktorem głównym jest klient, a aktorem pomocniczym jest administrator. Klient inicjuje przypadki użycia, takie jak rezerwacja, przeglądanie i anulowanie lotów, podczas gdy administrator inicjuje przypadki użycia, takie jak aktualizacja zapisów lotów, ale jest uważany za aktora pomocniczego w przypadku anulowania lotu, ponieważ tylko pomaga w realizacji przypadków użycia inicjowanych przez klienta.

Edytuj ten przykład diagramu przypadków użycia UML

Strukturyzacja przypadków użycia

Zgodnie z dziedziną zastosowania i wyborem projektanta, przypadek użycia może być podzielony na wiele przypadków użycia, które są połączone przez relacje < < include > > lub < < extend > >.

Link asocjacyjnyreprezentuje komunikację dwukierunkową między aktorem a przypadkiem użycia, a zatem jest relacją binarną. Ponieważ jest to komunikacja dwukierunkowa, dla każdego przypadku użycia inicjowanego przez aktora głównego, ten aktor musi otrzymać odpowiedź z przypadku użycia.

Podobnie, dla każdej komunikacji między przypadkiem użycia a aktorem pomocniczym (inicjowanej przez przypadek użycia), aktor pomocniczy musi wysłać odpowiedź z powrotem do przypadku użycia.

Generalizacja

Generalizacja reprezentuje związek między

• rolami lub
• przypadkami użycia.

Edytuj ten szablon diagramu przypadków użycia UML

Jeśli dwa aktorzy są połączeni tym związkiem, to aktor (lub przypadek użycia) na końcu strzałki (połączony z dolną częścią trójkąta) jest specjalizowaną wersją aktora (lub przypadku użycia) na drugim końcu.

Zazwyczaj aktor (lub przypadek użycia) na dolnym końcu (połączony z dolną częścią trójkąta) jest określany jako specjalizowana wersja aktora (lub przypadku użycia) na drugim końcu.

Generalizacja oznacza, że specjalizowana wersja ma wszystkie cechy wersji ogólnej, a być może nawet więcej.

Zawieraćjest specjalnym rodzajem relacji między dwoma przypadkami użycia. Jeśli przypadek użycia A zawiera inny przypadek użycia B, to wdrożenie A wymaga wdrożenia B, aby zakończyć swoje zadanie. Jednak B jest niezależne od siebie. To znaczy, że B nie musi wiedzieć nic o A. B może być również zawarte w każdym innym przypadku użycia.

Edytuj ten przykład diagramu przypadków użycia

Rozszerzyćjest kolejnym specjalnym rodzajem relacji między dwoma przypadkami użycia. Jeśli przypadek użycia B rozszerza inny przypadek użycia A, to wdrożenie A może warunkowo zawierać wdrożenie B, aby zakończyć swoje zadanie. To znaczy, w niektórych przypadkach A może zakończyć swoje zadanie bez B. Jednak w zależności od opisanych warunków.

Edytuj ten przykład diagramu przypadków użycia

Notacje diagramu przypadków użycia

Edytuj ten przykład diagramu przypadków użycia online

9 prostych kroków do przeprowadzenia analizy przypadków użycia

1. Określ, kto będzie bezpośrednio korzystał z systemu. Ci ludzie to aktorzy.
2. Wybierz jednego z tych aktorów.
3. Zdefiniuj, co ten aktor chce zrobić z systemem. Każda rzecz, którą aktor chce zrobić z systemem, staje się przypadkiem użycia.
4. Powtórz kroki 2-3 dla wszystkich innych przypadków użycia
   Zidentyfikuj role pomocnicze i wsparcie ról nie-ludzkich dla przypadków użycia, które zidentyfikowałeś.
5. Narysuj początkową wersję przypadku użycia, nie komplikuj na tym etapie relacji przypadków użycia
6. Omów i przejrzyj z użytkownikami, aby zweryfikować cele każdego przypadku użycia (korzyści z proponowanej funkcjonalności). Po modyfikacjach możesz kontynuować szczegółowe opracowywanie przypadków użycia w krokach 8 – 10
7. Dla każdego przypadku użycia zdecyduj, jaki będzie najczęstszy proces, który aktor będzie stosował podczas korzystania z systemu. Co zazwyczaj się wydarzy.
8. Opisz ten podstawowy proces w opisie przypadku użycia.
9. Gdy będziesz zadowolony z podstawowego procesu, rozważ alternatywne scenariusze i dodaj je jako rozszerzone przypadki użycia.

Model i specyfikacja przypadku użycia

Nie wystarczy tylko pokazać diagramu przypadków użycia w notacji UML. Każdemu przypadkowi użycia towarzyszy tekst, który wyjaśnia cel przypadku użycia oraz funkcjonalność, która jest realizowana, gdy przypadek użycia jest wykonywany.

Przypadek użycia opisuje zadanie wykonywane przez aktora, które przynosi wartość biznesową dla przedsiębiorstwa. Przypadek użycia można zobrazować jako diagram przypadku użycia lub/i w strukturalnej specyfikacji tekstowej formacie.

Scenariusze przypadków użycia

Przypadek użycia składa się z szeregu scenariuszy, z których każdy reprezentuje konkretną instancję przypadku użycia, odpowiadającą konkretnym danym wejściowym od aktora lub konkretnym warunkom w otoczeniu. Każdy scenariusz opisuje alternatywny sposób działania systemu lub może opisywać awarie lub wyjątki.

Przypadek użycia ma:

• Tylko jeden cel
• Jedno miejsce początkowe
• Jedno miejsce końcowe
• Wiele ścieżek do przejścia od początku do końca
  • tzn. Określ zachowanie dla różnych możliwych warunków
  • Każdy warunek może wymagać konkretnych działań

Na przykład – Klient płaci rachunek:

Istnieje wiele ścieżek do osiągnięcia celu:

• Płatność telefoniczna
• Pocztą
• Osobiście
• przez czek
• gotówką itp.

Ścieżka, która nie prowadzi do celu:

• Karta kredytowa została odrzucona

Grupowanie przypadków użycia w pakietach

Możesz także: Rysować pakiety do logicznej kategoryzacji przypadków użycia w powiązanych podsystemach.

Edytuj ten przykład diagramu przypadków użycia

Szczegółowa specyfikacja przypadku użycia

Szczegółowy przypadek użycia to tekstowa reprezentacja, która opisuje przebieg zdarzeń i inne powiązane informacje o przypadku użycia w określonym formacie. Standardowy szablon przypadku użycia jest często używany do dokumentowania szczegółów przypadku użycia.

Czym jest opis przypadku użycia

opis przypadku użyciajest pisemnym opisem sekwencji kroków, które analityk wykonuje, aby zakończyć pełną transakcję systemową. Jest inicjowany przez aktora, przynosi wartość temu aktorowi i jest celem aktorów pracujących w systemie.

Aktor – Każda osoba lub system zewnętrzny wobec systemu, który używa lub wchodzi w interakcję z systemem, aby osiągnąć cel. Każdemu aktorowi przypisywana jest rola, aby reprezentować ich interakcję z rozwiązaniem. Aktorzy ludzie powinni być nazywani w formie ról i nie powinni mieć przypisanych rzeczywistych imion. Aktorzy są zazwyczaj klasyfikowani jako główni, pomocniczy lub interesariusze.

Aktor główny – Aktor, który inicjuje przypadek użycia.
Aktor pomocniczy – Aktor, który reaguje lub odpowiada na działania wykonywane przez aktora głównego.
Interesariusze – aktorzy poza sceną, którzy nie wchodzą w bezpośrednią interakcję z przypadkiem użycia, ale mają interes w wyniku przypadku użycia.

Przebieg zdarzeń (ścieżka) – sekwencja kroków, które aktorzy i rozwiązania muszą podjąć, aby wykonać przypadek użycia. Ogólnie rzecz biorąc, przypadek użycia składa się z głównej ścieżki sukcesu (nazywanej również podstawową lub główną), alternatywnej ścieżki i ścieżki wyjątkowej.

Normalna ścieżka – wejście od aktora i odpowiedź od systemu – reprezentuje najczęstszą ścieżkę sukcesu w osiąganiu celów aktora.

Alternatywne ścieżki – wejścia od aktora i odpowiedzi systemu, reprezentujące inne, mniej powszechne ścieżki do osiągnięcia celu aktora

Wyjątkowe ścieżki – wejścia od aktora i odpowiedź systemu, reprezentujące nieudane ścieżki, gdy cel aktora nie może być osiągnięty.

Opis przypadku użycia
Nazwa przypadku użycia:	Wypłać gotówkę
Aktor(zy):	Klient (główny), System bankowy (pomocniczy)
Opis podsumowujący:	Pozwala każdemu klientowi banku wypłacić gotówkę z jego konta bankowego.
Priorytet:	Musi mieć
Status:	Średni poziom szczegółowości
Warunek wstępny:	Klient banku ma kartę do włożenia do bankomatu Bankomat działa poprawnie
Warunek(y) końcowy(e):	Klient banku otrzymał swoją gotówkę (i opcjonalnie paragon) Bank obciążył konto bankowe klienta i zarejestrował szczegóły transakcji
Podstawowa ścieżka:	Klient wkłada swoją kartę do bankomatu Bankomat weryfikuje, że karta jest ważną kartą bankową Bankomat prosi o kod PIN Klient wprowadza swój kod PIN Bankomat weryfikuje kartę bankową w odniesieniu do kodu PIN Bankomat przedstawia opcje usług, w tym „Wypłać” Klient wybiera „Wypłać” Bankomat przedstawia opcje kwot Klient wybiera kwotę lub wprowadza kwotę Bankomat weryfikuje, że ma wystarczającą ilość gotówki w swoim zasobniku Bankomat weryfikuje, że klient nie przekracza limitów wypłaty Bankomat weryfikuje wystarczające środki na koncie bankowym klienta Bankomat obciąża konto bankowe klienta Bankomat zwraca kartę bankową klienta Klient zabiera swoją kartę bankową Bankomat wydaje gotówkę klienta Klient zabiera swoją gotówkę
Alternatywne ścieżki:	2a. Nieprawidłowa karta 2b. Karta do góry nogami 5a. Sk stolen karta 5b. Nieprawidłowy PIN 10a. Niewystarczająca ilość gotówki w zasobniku 10b. Zła nominał gotówki w zasobniku 11a. Wypłata powyżej limitów wypłaty 12a. Niewystarczające środki na koncie bankowym klienta 14a. Karta bankowa utknęła w maszynie 15a. Klient nie zabiera swojej karty bankowej 16a. Gotówka utknęła w maszynie 17a. Klient nie zabiera swojej gotówki a Bankomat nie może komunikować się z systemem bankowym b Klient nie odpowiada na komunikat bankomatu
Zasady biznesowe:	B1: Format PIN-u B2: Liczba prób wprowadzenia PIN-u B3: Opcje usług B4: Opcje kwot B5: Limit wypłaty B6: karta musi być zabrana przed wydaniem gotówki
Wymagania niefunkcjonalne:	NF1: Czas na zakończenie transakcji NF2: Bezpieczeństwo wprowadzania PIN-u NF3: Czas na odebranie karty i gotówki NF4: Wsparcie językowe NF5: Wsparcie dla osób niewidomych i słabowidzących

Powiązane linki

1. Czym jest język modelowania UML?
2. Slajd przypadku użycia / Notatki wykładowe
3. Rola przypadków użycia w modelowaniu wymagań i analizy
4. Lista narzędzi UML
5. Wypróbuj Visual Paradigm ZA DARMO
6. Przypadek użycia – Notatki do kursu szkoleniowego
7. Jak pisać skuteczne przypadki użycia?
8. Rozdział książki – PDF – Model przypadku użycia: Pisanie wymagań w kontekście

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文