Istnieją dwa powszechne nieporozumienia dotyczące modelowania przypadków użycia:
Jednym z nich jest to, że diagram przypadków użycia jest zbyt prosty, ponieważ nie wyjaśnia niczego istotnego i nie ma sensu go rysować.
Drugim nieporozumieniem jest dokładnie odwrotność pierwszego. Niektórzy ludzie są przekonani, że diagram przypadków użycia jest tak potężny, że może przedstawiać wiele różnych aspektów oprogramowania – od opisywania wymagań systemu po modelowanie zachowań wewnętrznych systemu.
Czym więc jest przypadek użycia?
Czym jest diagram przypadków użycia
Czy modelowanie przypadków użycia jest proste czy potężne?
A przypadek użyciato lista czynności lub kroków zdarzeń, które zazwyczaj definiują interakcję między aktorem (nazywanym aktorem w języku modelowania jednolitym (UML)) a systemem w celu osiągnięcia celu. Aktorami mogą być ludzie lub inne systemy zewnętrzne. W inżynierii systemów przypadki użycia są stosowane na wyższym poziomie niż w inżynierii oprogramowania i zazwyczaj reprezentują cele zadania lub interesariuszy.
Czym jest diagram przypadków użycia?
Diagram przypadków użycia zazwyczaj jest prosty. Nie pokazuje szczegółów przypadków użycia:
- Zazwyczaj tylko podsumowujekilka relacjimiędzy przypadkami użycia, aktorami i systemami.
- Nie pokazujekolejnościw jakiej kolejności są wykonywane kroki w celu osiągnięcia celów każdego przypadku użycia.

Jak już powiedziano, diagram przypadków użycia powinien być prosty i zawierać tylko kilka kształtów. Jeśli zawiera więcej niż 20 przypadków użycia, prawdopodobnie niepoprawnie stosujesz diagram przypadków użycia.
Czym jest modelowanie przypadków użycia?
Modelowanie przypadków użycia to prosta odpowiedź na pytanie: „Co chce użytkownik (klient)?” Pozwala wizualnie przedstawić, co użytkownik chce osiągnąć, korzystając z końcowego produktu, który może być systemem, oprogramowaniem, programem itp. Modelowanie przypadków użycia to przydatna technika, która zapewnia programistom sólidy fundament do tworzenia systemów oprogramowania spełniających potrzeby klientów.
Mimo że notacja stosowana w diagramach przypadków użycia może wydawać się prosta i nie przekazywać wielu szczegółów, sposób zbierania, organizowania i rozwoju przypadków użycia ma istotny wpływ na kierunek cyklu rozwoju oprogramowania, a tym samym na jakość końcowego produktu oprogramowania.
10 praktycznych wskazówek dotyczących modelowania przypadków użycia
W tym artykule przejdziemy przez dziesięć wskazówek, które pozwolą maksymalnie zwiększyć skuteczność rysowania diagramów przypadków użycia. Nie będziemy szczegółowo wyjaśniać, czym jest przypadek użycia, ale omówimy kilka kluczowych koncepcji dotyczących modelowania UML, diagramów przypadków użycia i zbierania wymagań.
1. Myśl z perspektywy końcowego użytkownika
Jasne jest, że musisz znać oczekiwania użytkowników, aby stworzyć działający system oprogramowania, a ten zasada jest szczególnie ważna w modelowaniu przypadków użycia. Wiele osób błędnie traktuje modelowanie przypadków użycia jako proces modelowania funkcji systemu, co może być niepoprawne. Dokładniej mówiąc, modelowanie przypadków użycia to sposób modelowania tego, czego chcą użytkownicy. Każdy przypadek użycia na diagramie przypadków użycia powinien prowadzić do osiągnięcia zauważalnego celu poprzez interakcję użytkownika z końcowym oprogramowaniem lub systemem. Czasem cel użytkownika jest taki sam jak funkcja systemu, ale nie zawsze. Na przykład „Zaloguj się” to funkcja systemu, ale na pewno nie jest celem użytkownika – nikt nie uruchamia programu, się loguje i odchodzi! Dlatego im więcej funkcji systemu rysujesz na diagramie przypadków użycia, tym mniej skuteczny staje się model przypadków użycia w wyrażaniu rzeczywistych oczekiwań użytkownika w całym procesie rozwoju oprogramowania. Dlatego, gdy tworzysz model przypadków użycia, staraj się wyrazić wszystko, zaczynając od perspektywy końcowego użytkownika.
2. Unikaj długich nazw przypadków użycia
Jeśli czytasz diagram przypadków użycia przygotowany dla systemu bankomatu, które z poniższych przypadków użycia chciałbyś zobaczyć na diagramie? „Wypłać gotówkę” i „Wypłać gotówkę i zaktualizuj stan konta”. Drugi przypadek wydaje się bardziej opisowy, prawda? A co z posiadaniem 50+ różnych przypadków użycia o tak długiej nazwie? Prawdopodobnie nie chcesz już czytać diagramu i może nawet bolać Cię oczy.
Jednym z powodów, dla których potrzebujemy modelowania, jest chęć zrozumienia złożonego systemu oprogramowania w łatwy i prosty sposób. Dlatego UML zapewnił nam wiele różnych rodzajów notacji, z których każda reprezentuje konkretną perspektywę opisu kompletnego systemu oprogramowania. Ten „duszewny” kierunek dotyczy również nadawania nazw przypadkom użycia. Jeśli próbujemy nadać przypadkom użycia nazwy z szczegółowym opisem, dlaczego nie użyć po prostu pliku tekstowego? Aby diagram przypadków użycia był łatwy do zrozumienia, ważne jest, by nazwy przypadków użycia były krótkie, ale nadal opisowe. Zachowaj krótkie nazwy i szczegółowy opis przesuń do sekcji opisu przypadków użycia.
3. Aktor to rola, a nie osoba rzeczywista
Niektórzy ludzie próbują przedstawić pracowników w organizacji jako aktorów na diagramie przypadków użycia, co kończy się diagramem z Peterem, Mary, Daisy itd. Pamiętaj, że aktor reprezentuje unikalną rolę, która składa się z ludzi, podsystemów lub innych jednostek o unikalnych cechach i wspólnych celach oraz oczekiwaniach.
4. Modeluj wspólny przypadek użycia za pomocą relacji
Przypadek użycia reprezentuje cel użytkownika, który może zostać osiągnięty poprzez przejście przez serię kroków. Gdy dokładnie te same kroki pojawiają się w różnych przypadkach użycia, możesz opcjonalnie stworzyć nowy przypadek użycia dla wspólnych kroków i połączyć go z przypadkami użycia, które wywołują te kroki. Używając przypadku użycia dołączanego, jasno pokazuje się, że przypadki użycia zawierające go rzeczywiście dzielą te same kroki, które reprezentuje dołączony przypadek użycia, bez żadnej niepewności.
5. Modeluj zachowanie wyjątkowe
Relacja Extend może być używana do określenia, kiedy i jak zachowanie przypadku użycia może zostać wyzwolone przez inny przypadek użycia. Rozszerzenie odbywa się w punktach rozszerzenia zdefiniowanych w rozszerzanym przypadku użycia. Przypadek rozszerzający definiuje kroki, które mogą zostać wykonane przez rozszerzony przypadek użycia w określonych warunkach.
6. Modeluj scenariusz za pomocą przepływu zdarzeń
Przypadek użycia reprezentuje cel użytkownika, który może zostać osiągnięty poprzez przejście przez sekwencję kroków. Niektórzy ludzie próbują modelować kroki bezpośrednio na diagramie przypadków użycia, łącząc aktora i przypadek użycia za pomocą wielu połączeń, udając, że są to kroki, co jest na pewno błędne. Zamiast tego kroki przypadku użycia mogą być dobrze opisane w edytorze przepływu zdarzeń przypadku użyciaedytor przepływu zdarzeń.
Edytor przepływu zdarzeń ma postać tabelaryczną, przy czym każdy wiersz reprezentuje krok przypadku użycia. Możesz tam zapisać kroki, z lub bez przepływu warunkowego. Możesz również stosować formatowanie tekstu w celu wyróżnienia kluczowych idei.
7. Skorzystaj odpowiednio ze stereotypów do kategoryzacji
Stereotyp to mechanizm, który pozwala wprowadzić specyficzne dla dziedziny oznaczenia dodatkowo do standardowych. Stereotyp jest wyświetlany w parach znaków guillemetów, na górze nazwy kształtu, gdy stereotyp jest zastosowany. Poprawne użycie stereotypu pomaga czytelnikom łatwiej zrozumieć różnice między przypadkami użycia.
8. Modeluj szczegółowy przepływ systemu za pomocą diagramu sekwencji
Diagram sekwencjipozwala na modelowanie zachowania systemu poprzez przedstawienie komunikacji i wymiany wiadomości między obiektami w czasie. Ale od czego zacząć? Zamiast zgadywać, co modelować, możesz zacząć od odniesienia się do potrzeb użytkownika, co dokładnie ma przedstawiać model przypadku użycia.
Wiemy, że każdy przypadek użycia reprezentuje unikalny cel użytkownika. Rysowanie diagramu sekwencji na podstawie przypadku użycia oznacza, że modelujesz to, co system komputerowy powinien zrobić, aby spełnić potrzeby użytkownika. Idealnie, nie będzie żadnego nadmiarowego projektowania, ponieważ wszystkie diagramy sekwencji są tworzone na podstawie przypadków użycia, które reprezentują potrzeby użytkownika.
9. Stosuj tę samą szerokość przypadków użycia, gdy to odpowiednie
Ponieważ nazwy przypadków użycia różnią się długością, jest normalne, że przypadki użycia mają różną szerokość. Aby zrobić diagram bardziej estetyczny i łatwiejszy do odczytania, dobrze byłoby zmienić ich rozmiar, aby miały tę samą szerokość.
10. Umieszczaj aktorów i przypadki użycia w sposób znaczący
Diagram przypadków użycia z losowo rozmieszczonymi aktorami i przypadkami użycia to na pewno koszmar dla czytelników. Należy dokładnie przeanalizować diagram, aby znaleźć informacje, które chce się uzyskać z rozrzuconych aktorów i przypadków użycia. Byłoby dobrze umieszczać kształty w sposób uporządkowany. Możesz również grupować przypadki użycia za pomocą kształtów pakietów, jeśli to konieczne.
Zródła:
- Co to jest diagram przypadków użycia?
- Rodzaje aktorów w modelu przypadków użycia
- Identyfikuj wymagania użytkownika za pomocą diagramów przypadków użycia
- Co to jest specyfikacja przypadku użycia?
- Prawdziwy przewodnik po analizie odporności
- Historia użytkownika w porównaniu do przypadku użycia w rozwoju oprogramowania agilnego
- Metoda oparta na przypadkach użycia w rozwoju agilnym




