U

U

se case

se case

-

-

przypadk

przypadk

i

i

u

u

ż

ż

ycia

ycia

czyli

czyli

o co w tym wszystkim

o co w tym wszystkim

chodzi

chodzi

V ZIN
3

Mateusz Walicki

Marek Zadworny

Rafał Szymański

Tworzenie przypadków użycia

(ang. use case) to technika

stosowana

w inżynierii oprogramowania w celu

opisania wymagań tworzonego

systemu informatycznego.

Przypadek użycia przedstawia

interakcję pomiędzy aktorem

(użytkownikiem systemu),

który inicjuje zdarzenie

oraz samym systemem

jako sekwencję prostych kroków.

Przypadek użycia powinien:

• opisywać w jaki sposób system
powinien być używany przez aktora w
celu osiągnięcia konkretnego celu

• być pozbawiony szczegółów
dotyczących implementacji oraz
interfejsu użytkownika

• opisywać system na właściwym
poziomie szczegółowości

Nazewnictwo:

Zaleca się, aby przypadki użycia
posiadały nazwy odpowiadające
czynnościom, które opisują.

Często zaleca się stosowanie wyrażeń
rozpoczynających się od czasownika w
formie trybu rozkazującego.

Przykładowe nazwy to:

"Zarejestruj użytkownika",

"Sprawdź stan konta".

Przypadek użycia powinien przedstawiać
podstawowy przebieg operacji, tzw.
szczęśliwą ścieżkę wydarzeń ("basic
flow", "happy flow").

Przykład:

•System prosi Użytkownika o
zalogowanie

•Użytkownik podaje swój numer
identyfikacyjny oraz hasło

•System stwierdza poprawność danych
•Użytkownik zostaje zalogowany do
systemu

Diagram przypadków użycia w języku
UML służy do modelowania
funkcjonalności systemu.

Tworzony jest zazwyczaj w początkowych
fazach modelowania.

Diagram ten stanowi tylko przegląd
możliwych działań w systemie, szczegóły
ich przebiegu są modelowane za pomocą
innych technik (np. diagramów stanu lub
aktywności).

Diagram przypadków użycia składa się

z następujących kategorii pojęciowych:

* przypadków użycia,

* aktorów,

* związków.

Przypadek użycia (ang. use case) -
specyfikacja ciągu akcji i ich wariantów,
które system (lub inna jednostka) może
wykonać poprzez interakcję z aktorami
tego systemu.

Według standardu UML reprezentowany
jest przez elipsę z etykietą umieszczoną
wewnątrz figury.

Przyjęcie

zgłoszenia

Aktor (ang. actor) - spójny zbiór ról
odgrywanych przez użytkowników
przypadku użycia w czasie interakcji z
tym przypadkiem użycia.

Nie o takiego aktora
chodzi !!!

Wyróżniamy aktorów osobowych i
nieosobowych.

Aktorem osobowym może być osoba,
zespół, dział, instytucja, organizacja,
zrzeszenie organizacji lub organizacja
wirtualna.

Nazwy aktorów osobowych często
pokrywają się z nazwami funkcji jakie
pełnią w organizacji, projekcie lub
przedsięwzięciu bądź nazwą stanowiska
jakie piastują.

Natomiast aktorem bezosobowym może
być system zewnętrzny (podsystemy,
bazy danych), urządzenie lub czas.

Technik

serwisu

Graficzne przedstawienie aktora

Związek (ang. relationship) -
semantyczne powiązanie pomiędzy
elementami modelu.

Każdy aktor, który jest na diagramie
przypadków użycia musi być
bezpośrednio powiązany z co najmniej
jednym przypadkiem użycia. Podobnie
każdy przypadek użycia musi być
użytkowany co najmniej przez jednego
aktora (niejednokrotnie są to powiązania
pośrednie).

Graficzne przedstawienie związku

Realizacja

zlecenia

Technik
serwisu

Stopień szczegółowości diagramów

Model przypadków użycia dostarcza
bardzo abstrakcyjnego spojrzenia na
system - spojrzenia z pozycji aktorów,
którzy go używają.

Nie włącza zbyt wielu szczegółów, co
pozwala wnioskować o funkcjonalności
systemu na odpowiednio wysokim
poziomie. Podstawowym (choć nie
jedynym) zastosowaniem jest tu dialog z
przyszłymi użytkownikami zmierzający
do sformułowania poprawnych wymagań
na system.

Wskazówki

• Dla każdego aktora, znajdź funkcje (zadania), które
powinien wykonywać w związku z jego działalnością w
zakresie zarówno dziedziny przedmiotowej, jak i
wspomagania działalności systemu informacyjnego.

• Staraj się powiązać w jeden przypadek użycia zespół
funkcji realizujących podobne cele. Unikaj rozbicia
jednego przypadku użycia na zbyt wiele pod-
przypadków.

• Nazwy dla przypadków użycia: powinny być krótkie,
ale jednoznacznie określające charakter zadania lub
funkcji. Nazwy powinny odzwierciedlać czynności z
punktu widzenia aktorów, a nie systemu, np.
"wpłacanie pieniędzy", a nie "przyjęcie pieniędzy od
klienta".

• Opisz przypadki użycia przy pomocy zdań w języku
naturalnym, używając terminów ze słownika.

Wskazówki

• Uporządkuj aktorów i przypadki użycia w postaci
diagramu.

• Niektóre z powstałych w ten sposób przypadków
użycia mogą być mutacjami lub szczególnymi
przypadkami innych przypadków użycia. Przeanalizuj
powiązania aktorów z przypadkami użycia i ustal,
które z nich są zbędne lub mogą być uogólnione.

• Wyodrębnij "przypadki bazowe", czyli te, które
stanowią istotę zadań, są normalnym, standardowym
użyciem. Pomiń czynności skrajne, wyjątkowe,
uzupełniające lub opcje.

• Nazwij te przypadki bazowe. Ustal powiązania
przypadków bazowych z innymi przypadkami, poprzez
ustalenie ich wzajemnej zależności: sekwencji czy
alternatywy.

Wskazówki

• Dodaj zachowania skrajne, wyjątkowe,
uzupełniające lub opcjonalne. Ustal powiązanie
przypadków bazowych z tego rodzaju zachowaniem.
Może ono być także powiązane w pewną strukturę.

• Staraj się, aby bloki specyfikowane wewnątrz
każdego przypadku użycia nie były zbyt ogólne lub
zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają
analizę. Zbyt ogólne bloki zmniejszają możliwość
wykrycia bloków ponownego użycia. Struktura nie
może być zbyt duża i złożona.

• Staraj się wyizolować bloki ponownego użycia.
Przeanalizuj podobieństwo nazw przypadków użycia,
podobieństwo nazw i zachowania bloków ponownego
użycia występujących w ich specyfikacji. Wydzielenie
bloku ponownego użycia może być powiązane z
określeniem bardziej ogólnej funkcji lub dodaniu
nowej specjalizacji do istniejącej funkcji.

KONIEC

KONIEC

Dziękujemy za uwagę

Informacje wykorzystane w prezentacji

pochodzą ze strony www.wikipedia.pl