Diagram przypadków użycia UML jest główną formą wymagań systemowych/oprogramowania dla nowego oprogramowania w trakcie rozwoju. Przypadki użycia określają oczekiwane zachowanie (co) systemu, a nie dokładną metodę jego realizacji (jak). Kompletny zestaw przypadków użycia określa wszystkie różne sposoby użycia systemu i tym samym definiuje wszystkie wymagane zachowania systemu, ograniczając zakres systemu.
Kluczowym pojęciem modelowania przypadków użycia jest to, że pomaga nam projektować system z perspektywy użytkownika końcowego. Jest to efektywna technika komunikowania zachowania systemu w kategoriach użytkownika, określając wszystkie zewnętrznie widoczne zachowania systemu.
Diagram przypadków użycia w skrócie
Standardowa forma diagramu przypadków użycia jest zdefiniowana w Unified Modeling Language, jak pokazano na przykładzie diagramu przypadków użycia poniżej:
Co to jest przypadek użycia?
- Przypadek użycia to zbiór możliwych sekwencji interakcji między rozpatrywanym systemem a jego zewnętrznymi aktorami związanymi z określonym celem.
- Każdy przypadek użycia to kompletny przebieg wydarzeń w systemie z perspektywy użytkownika.
- Przypadki użycia, po zdefiniowaniu, mogą być przedstawione zarówno tekstowo, jak i wizualnie (np. diagram przypadków użycia).
- Przypadki użycia są metodą preferowaną przez społeczność komponentów i obiektów do specyfikowania wymagań oraz do sterowania całym procesem rozwoju oprogramowania.
- Przypadki użycia zwykle dotyczą dość istotnych zadań; nie muszą być pisane dla każdej akcji, jaką może podjąć użytkownik.
Korzyści z podejścia przypadków użycia
Przypadki użycia oferują wiele korzyści poza definiowaniem wymagań użytkownika. Przypadki użycia mogą być wykorzystane do:
- Przypadki użycia pomagają w uchwyceniu wymagań funkcjonalnych systemu.
- Przypadki użycia są śledzone.
- Przypadki użycia mogą służyć jako podstawa do szacowania, planowania i weryfikacji wysiłku.
- Przypadek użycia może ewoluować na każdej iteracji od metody uchwytywania wymagań, poprzez wytyczne rozwoju dla programistów, do przypadku testowego i ostatecznie do dokumentacji użytkownika.
- Alternatywne ścieżki przypadków użycia uchwytują dodatkowe zachowania, które mogą poprawić odporność systemu.
- Przypadki użycia okazały się łatwe do zrozumienia przez użytkowników biznesowych i tym samym stanowią doskonały mostek między deweloperami oprogramowania a użytkownikami końcowymi.
- Identyfikowanie klas domen biznesowych i ich powiązań
Aktor
- Ktoś interaktywny z przypadkiem użycia (funkcją systemu).
- Nazwany rzeczownikiem.
- Aktor odgrywa rolę w biznesie
- Podobny do pojęcia użytkownika, ale użytkownik może pełnić różne role
- Na przykład:
- Profesor może być instruktorem i jednocześnie badaczem
- Odgrywa dwie role z dwoma systemami
- Aktor inicjuje przypadek (przypadki) użycia.
- Aktor ma odpowiedzialność wobec systemu (wejścia), a Aktor ma oczekiwania wobec systemu (wyjścia).
Przypadek użycia
- Funkcja systemu (proces — automatyczny lub ręczny)
- Nazwany czasownikiem + rzeczownikiem (lub frazą rzeczownikową).
- np. Zrób coś
- Każdy Aktor musi być powiązany z przypadkiem użycia, podczas gdy niektóre przypadki użycia mogą nie być powiązane z aktorami.
Łącze komunikacyjne
- Udział aktora w przypadku użycia jest przedstawiany przez połączenie aktora z przypadkiem użycia za pomocą łącza stałego.
- Aktorzy mogą być połączeni z przypadkami użycia przez powiązania, co oznacza, że aktor i przypadek użycia komunikują się ze sobą za pomocą wiadomości.
Granica systemu
- Granica systemu to potencjalnie cały system, tak jak zdefiniowano w dokumencie wymagań.
- Dla dużych i złożonych systemów każdy moduł może być granicą systemu.
- Na przykład, dla systemu ERP dla organizacji każdy z modułów, takich jak personalny, płace, księgowość itp.
- może tworzyć granicę systemu dla przypadków użycia specyficznych dla każdej z tych funkcji biznesowych.
- Cały system może obejmować wszystkie te moduły, przedstawiając ogólną granicę systemu
6 kroków analizy przypadków użycia
Podczas tworzenia przypadków użycia należy zacząć od podziału funkcjonalnego — listy głównych kategorii funkcjonalnych docelowego systemu. To pomoże zidentyfikować obszary, na które należy skupić uwagę.
Krok 1 — zidentyfikuj aktorów: Zidentyfikuj, kto będzie bezpośrednio używał systemu. To są aktorzy.
- Jednym z głównych składników tworzenia przypadków użycia są aktorzy.
- Aktor to określona rola odgrywana przez użytkownika systemu i reprezentuje kategorię użytkowników, którzy wykazują podobne zachowania podczas korzystania z systemu.
- Aktorami mogą być ludzie lub systemy komputerowe.
- Główny aktor to taki, który ma cel wymagający wsparcia systemu.
- Aktor pomocniczy to taki, od którego system potrzebuje wsparcia, aby zaspokoić swój cel.
- Jeden z aktorów jest oznaczony jako system w dyskusji.
- Osoba może pełnić wiele ról i tym samym reprezentować wielu aktorów, takich jak operator systemu komputerowego lub użytkownik końcowy.
Krok 2: Wybierz jednego z tych aktorów.
- Aby zidentyfikować przypadek użycia docelowego systemu, identyfikujemy aktorów systemu.
- Dobrym punktem wyjścia jest sprawdzenie projektu systemu i zidentyfikowanie, komu ma pomagać.
Krok 3 — zidentyfikuj przypadki użycia: Zdefiniuj, co aktor chce zrobić z systemem. Każda z tych rzeczy, które aktor chce zrobić z systemem, staje się przypadkiem użycia.
- Rzeczy, które aktorzy chcą zrobić z systemem, stają się celami.
- Celem jest końcowy wynik działań użytkownika. Istnieją dwa rodzaje celów. Pierwszy rodzaj to sztywny cel.
- Ten cel musi być całkowicie zaspokojony i opisuje minimalne wymagania docelowego systemu.
- Aby zidentyfikować przypadki użycia, możemy przeczytać specyfikację wymagań z perspektywy aktora i prowadzić dyskusje z tymi użytkownikami, którzy będą funkcjonować jako aktorzy.
- Poprzez zdefiniowanie wszystkiego, co każdy aktor będzie mógł zrobić w interakcji z systemem, definiuje się kompletną funkcjonalność systemu.
Krok 4 — zidentyfikuj standardowy scenariusz przypadku użycia: Dla każdego z tych przypadków użycia zdecyduj o najbardziej typowym przebiegu, gdy aktor używa systemu. Co zwykle się dzieje.
- Przypadek użycia ma jeden podstawowy przebieg i kilka alternatywnych przebiegów.
- Podstawowy przebieg jest najprostszym przebiegiem, w którym żądanie jest realizowane bez trudności.
- Może istnieć kilka alternatywnych przebiegów, które opisują warianty przebiegu podstawowego i błędy, które mogą wystąpić.
- Są one dokumentowane jako rozszerzenia przypadku użycia.
Krok 5 — opracuj opis przypadku użycia: Opisz ten podstawowy przebieg w opisie przypadku użycia.
- Scenariusz użycia jest pisany z perspektywy użytkownika w łatwy do zrozumienia język.
- Kroki niezbędne do osiągnięcia zidentyfikowanego celu są opisane, znane jako przebieg wydarzeń.
Krok 6 — opracuj alternatywne ścieżki przypadku użycia: Gdy jesteś zadowolony z podstawowego przebiegu, rozważ teraz alternatywy i dodaj je jako rozszerzenia przypadków użycia.
Alternatywne scenariusze przypadku użycia
Przypadek użycia opisuje również, jak system powinien reagować, gdy coś nie idzie dobrze lub gdy coś idzie dobrze, ale nie tak, jak opisaliśmy w głównym scenariuszu sukcesu. Nazywamy te sytuacje rozszerzeniami.
- Istnieją dwa rodzaje: wyjątki i alternatywy.
- Wyjątki to warunki błędu (coś poszło źle).
- Alternatywy to po prostu inny sposób, aby coś poszło dobrze.
Poziomy szczegółowości przypadków użycia
Granularność przypadków użycia odnosi się do sposobu organizacji informacji w specyfikacjach przypadków użycia oraz do pewnego stopnia do poziomu szczegółowości, na jakim są pisane. Osiągnięcie odpowiedniego poziomu granularności przypadków użycia ułatwia komunikację między interesariuszami a deweloperami i poprawia planowanie projektu.
Alastair Cockburn w książce Writing Effective Use Cases daje nam łatwy sposób na wizualizację różnych poziomów celów, myśląc w kategoriach morza:
Należy pamiętać, że:
- Chociaż sam przypadek użycia może szczegółowo analizować każdą możliwość, diagram przypadków użycia często służy do przedstawienia systemu na wyższym poziomie jako planów.
- Jest korzystne pisać przypadki użycia na grubszym poziomie granularności z mniejszą ilością szczegółów, gdy nie jest to konieczne.
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.
Źródła
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文