Wszystko, co musisz wiedzieć o modelowaniu przypadków użycia

Korzyści z diagramu przypadków użycia

1. Przypadki użycia to potężna technika do wydobywania i dokumentowania wymagań funkcjonalnych czarnej skrzynki.
2. Ponieważ przypadki użycia są łatwe do zrozumienia i stanowią doskonały sposób komunikacji z klientami i użytkownikami, ponieważ są napisane w języku naturalnym.
3. Przypadki użycia mogą pomóc w zarządzaniu złożonością dużych projektów, dzieląc problem na główne funkcje użytkowników (tj. przypadki użycia) oraz określając aplikacje z perspektywy użytkowników.
4. Scenariusz przypadku użycia, często reprezentowany przez diagram sekwencji, obejmuje współpracę wielu obiektów i klas, przypadki użycia pomagają zidentyfikować wiadomości (operacje oraz informacje lub dane wymagane — parametry), które łączą obiekty i klasy.
5. Przypadki użycia stanowią dobrą podstawę do powiązania weryfikacji modeli wyższego poziomu (tj. interakcja między aktorami a zestawem obiektów współpracujących) oraz następnie do walidacji wymagań funkcjonalnych (tj. plan testów białoskrzynkowych).
6. Podejście oparte na przypadkach użycia zapewnia ścisłe powiązania do śledzenia projektu, w którym kluczowe działania rozwojowe, takie jak przypadki użycia, są wdrażane, testowane i dostarczane, spełniając cele i założenia z punktu widzenia użytkownika.

Jak narysować diagram przypadków użycia?

Model przypadku użycia można opracować, postępując zgodnie z poniższymi krokami.

1. Zidentyfikuj aktorów (rolę użytkowników) systemu.
2. Dla każdej kategorii użytkowników zidentyfikuj wszystkie role odgrywane przez użytkowników istotne dla systemu.
3. Zidentyfikuj, co użytkownicy wymagają od systemu, aby osiągnąć te cele.
4. Utwórz przypadki użycia dla każdego celu.
5. Zorganizuj przypadki użycia.
6. Priorytetyzuj, przeglądaj, szacuj i waliduj użytkowników.

Zauważ, że aby podejście do przypadków użycia było bardziej „zwinne”, nie szczegółuj wszystkich przypadków użycia, ale priorytetyzuj je w swoim backlogu produktu, powinieneś doprecyzować przypadek użycia na różnych poziomach szczegółowości w zależności od fazy rozwoju w sposób na czas i wystarczający.

Możesz również:

1. Rysuj pakiety dla logicznej kategoryzacji przypadków użycia w powiązanych podsystemach.

Struktura przypadków użycia

UML definiuje trzy stereotypy asocjacji między przypadkami użycia:

<<include>> Przypadek użycia

Czas na użycie relacji <<include>> następuje po ukończeniu pierwszego opisu wszystkich głównych przypadków użycia. Teraz możesz spojrzeć na przypadki użycia i zidentyfikować wspólne sekwencje interakcji użytkownika z systemem.

<<extend>> Przypadek użycia

Rozszerzający przypadek użycia jest w rzeczywistości alternatywną ścieżką podstawowego przypadku użycia. Przypadek użycia <<extend>> osiąga to, konceptualnie wstawiając dodatkowe sekwencje działań do sekwencji podstawowego przypadku użycia.

Abstrakcyjny i uogólniony przypadek użycia

Ogólny przypadek użycia jest abstrakcyjny. Nie może być zainstancjonowany, ponieważ zawiera niekompletne informacje. Tytuł abstrakcyjnego przypadku użycia jest wyświetlany kursywą.

Przykład

Ten przykład przedstawia model kilku przypadków użycia biznesowego (celów), który reprezentuje interakcje między restauracją (systemem biznesowym) a jej głównymi aktorami.

Po zidentyfikowaniu podstawowych przypadków użycia w pierwszym podejściu, być może moglibyśmy dalej zorganizować te przypadki użycia z przypadkami użycia <<extend>> i <<include>> w drugiej rundzie poprawek, jak pokazano na poniższym rysunku:

Przypadek użycia biznesowego

Przypadek użycia biznesowego jest opisany w terminologii wolnej od technologii która traktuje proces biznesowy jako czarną skrzynkę i opisuje proces biznesowy, który jest używany przez jego aktorów biznesowych, podczas gdy zwykły przypadek użycia jest zazwyczaj opisywany na poziomie funkcjonalności systemu i określa funkcję lub usługę, którą system zapewnia użytkownikowi. Innymi słowy, przypadek użycia biznesowego reprezentuje, jak praca ma być wykonywana ręcznie w obecnej sytuacji i niekoniecznie jest wykonywana przez system ani nie ma na celu automatyzacji w zakresie docelowego systemu.

Jak zidentyfikować aktorów

Często ludzie uważają, że najłatwiej jest rozpocząć proces pozyskiwania wymagań od zidentyfikowania aktorów. Poniższe pytania mogą pomóc w zidentyfikowaniu aktorów twojego systemu (Schneider i Winters — 1998):

• Kto korzysta z systemu?
• Kto instaluje system?
• Kto uruchamia system?
• Kto utrzymuje system?
• Kto zamyka system?
• Jakie inne systemy korzystają z tego systemu?
• Kto uzyskuje informacje z tego systemu?
• Kto dostarcza informacje do systemu?
• Czy coś dzieje się automatycznie w danym momencie?

Jak zidentyfikować przypadki użycia?

Identyfikacja przypadków użycia, a następnie proces pozyskiwania wymagań oparty na scenariuszach polega na zadawaniu pytań o to, jaką zewnętrznie widoczną, obserwowalną wartość każdy aktor pragnie. Poniższe pytania można zadać, aby zidentyfikować przypadki użycia, gdy twoi aktorzy zostaną zidentyfikowani (Schneider i Winters — 1998):

• Jakie funkcje aktor będzie chciał uzyskać z systemu?
• Czy system przechowuje informacje? Jakie aktory będą tworzyć, odczytywać, aktualizować lub usuwać te informacje?
• Czy system musi powiadomić aktora o zmianach w stanie wewnętrznym?
• Czy są jakieś zewnętrzne zdarzenia, o których system musi wiedzieć? Który aktor informuje system o tych zdarzeniach?

Wskazówki dotyczące diagramu przypadków użycia

Teraz sprawdź poniższe wskazówki, aby zobaczyć, jak skutecznie zastosować przypadki użycia w swoim projekcie oprogramowania.

• Zawsze strukturyzuj i organizuj diagram przypadków użycia z perspektywy aktorów.
• Przypadki użycia powinny zaczynać się od prostoty i na najwyższym możliwym poziomie. Tylko wtedy mogą być doprecyzowane i szczegółowo opisane.
• Diagramy przypadków użycia opierają się na funkcjonalności i dlatego powinny koncentrować się na „co”, a nie na „jak”.

Poziomy szczegółowości przypadków użycia

Granularność przypadków użycia odnosi się do sposobu, w jaki informacje są zorganizowane w specyfikacjach przypadków użycia, a w pewnym stopniu do poziomu szczegółowości, na jakim są napisane. Osiągnięcie odpowiedniego poziomu granularności przypadków użycia ułatwia komunikację między interesariuszami a deweloperami oraz poprawia planowanie projektu.

Alastair Cockburn w Pisanie efektywnych przypadków użyciadaje nam łatwy sposób na wizualizację różnych poziomów celów, myśląc w kategoriach morza:

Zauważ, że:

• Podczas gdy przypadek użycia może zagłębiać się w wiele szczegółów dotyczących każdej możliwości, diagram przypadków użycia często może być używany do wyższego poziomu widoku systemu jako planów.
• Korzystne jest pisanie przypadków użycia na bardziej ogólnym poziomie granularności z mniejszą ilością szczegółów, gdy nie jest to wymagane.

Mam nadzieję, że teraz możesz odpowiedzieć na pytanie „co to jest diagram przypadków użycia” i zastosować przypadki użycia w swoim projekcie. Jeśli chcesz dowiedzieć się więcej o innych typach diagramów UML, sprawdź przewodnik UML: Przegląd 14 typów diagramów UML.

Pokazanie tylko diagramu przypadków użycia w UMLnotacja nie jest wystarczająca. Każdy przypadek użycia powinien być opatrzony tekstem wyjaśniającym cel przypadku użycia oraz funkcjonalność, która jest realizowana, gdy przypadek użycia jest wykonywany.

Specyfikacja przypadków użycia jest zazwyczaj tworzona w fazie analizy i projektowania w sposób iteracyjny.

• Na początku pisana jest tylko krótka charakterystyka kroków potrzebnych do przeprowadzenia normalnego przebiegu przypadku użycia (tj. jaką funkcjonalność zapewnia przypadek użycia).
• W miarę postępu analizy kroki są rozwijane, aby dodać więcej szczegółów.
• Na koniec do przypadku użycia dodawane są wyjątki.
• Każdy projekt może przyjąć standardowy szablon przypadku użycia do tworzenia specyfikacji przypadków użycia.

Przypadek użycia vs Specyfikacja przypadku użycia

Przypadek użycia opisuje zadanie wykonywane przez aktora, które przynosi wynik o wartości biznesowej dla firmy. Przypadek użycia może być wizualizowany jako diagram przypadków użycia lub/i w ustrukturyzowanym formacie specyfikacji tekstowej:

Przypadek użycia (zadanie — klient chce wykonać) może być:

• Interaktywny — przypadek użycia systemu opisuje interakcję aktora z systemem w dążeniu do określonego celu biznesowego
• Ręczny — sekwencja działań wykonywanych przez aktora
• Zautomatyzowany — sekwencja kroków wykonywanych przez program lub skrypt

Cechy przypadków użycia

Przypadek użycia ma:

• Tylko jeden cel
• Jedno miejsce początkowe
• Jedno miejsce końcowe
• Wiele ścieżek prowadzących 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ą, itd.

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

• Karta kredytowa została odrzucona

Zwinne podejście do przypadków użycia

Model przypadków użycia i jego poszczególne przypadki użycia ewoluują poziom po poziomie w czasie. Nie wszystkie przypadki użycia modelu będą musiały być koniecznie określone na tym samym poziomie szczegółowości.

Na czas i wystarczająco

Przypadki użycia mogą być pisane na różnych poziomach danych i zakresu, każdy z nich ma swoje przeznaczenie:

• Podsumowanie: Ogólne opisy i szerokie przeglądy funkcjonalności systemu lub procesów biznesowych.
• Poziom użytkownika: Opisy związane z zadaniami użytkowników i ich interakcjami z systemem; opisy konkretnego procesu biznesowego. Przypadki użycia na poziomie użytkownika są zazwyczaj uważane za poziom zadania, które jest główną pracą użytkownika.
• Podfunkcja: Opisy niższych działań, które są używane do ukończenia podczęści podstawowego przypadku użycia.

Uwaga: Niektóre przypadki użycia mogą być wystarczająco określone do poziomu II. Zatrzymujesz się, gdy osiągniesz wystarczający poziom szczegółowości w sposób na czas i wystarczająco.

Szczegółowa specyfikacja przypadku użycia

Szczegółowy przypadek użycia to tekstowa reprezentacja ilustrująca sekwencję zdarzeń wraz z innymi powiązanymi informacjami o przypadkach użycia w określonym formacie. Ludzie zazwyczaj przyjmują standardowy szablon przypadku użycia do rejestrowania szczegółowych informacji o przypadkach użycia.