USE CASES - przypadki u¿ycia

Przypadki użycia (use cases)
Po co są przypadki użycia ?
9Próby definicji
9Podstawowe pojęcia
9Notacje
9Relacje
9Dokumentacja
9Kroki metody
9Przykłady
9
Przypadki użycia (use cases)
Po co są przypadki użycia ?
Gdy projektujemy jakikolwiek system, najważniejszym etapem jest
!!! określenie wymagań !!!
Podejście przypadków użycia ma przede wszystkim na względzie ten problem.
Przypadki użycia (use cases)
Definicje
Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego
użytkownicy.
Przypadek użycia specyfikuje zachowanie systemu lub jego części. Jest to
opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w
celu dostarczenia określonemu aktorowi godnego uwagi wyniku
Ich głównym celem jest odwzorowanie funkcji projektowanego systemu w
taki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach
opartych na UML przypadkom użycia przypisuje się szczególne znaczenie jako
środka napędzającego cały proces rozwoju systemu.
Przypadki użycia (use cases)
Przypadki użycia w analizie
Eksperci
Doświadczenie
w dziedzinie
przedmiotowej
Potrzeby
Pomysły
Model
dziedziny
Kompletny
model
analizy
Koncepcja
zastosowania
Przypadki
użycia
Technologie
Model
zastosowania
Użytkownicy
mocny wpływ
słaby wpływ
Przypadki użycia (use cases)
Przypadki użycia w analizie c.d.
Cele :
• głębsze zrozumienie użycia systemu (z punktu widzenia
użytkownika)
• zwiekszenie stopnia świadomości analityków i projektantów
• umożliwienie interakcji zespołu projektowego z przyszłymi
użytkownikami systemu
• weryfikacja poprawności i kompletności projektu
• ustalenie składowych systemu i związanego z nimi planu
konstrukcji systemu
• dostarczenie podstawy do sporządzenia planu testów
systemu
Przypadki użycia (use cases)
Projektowanie mieszkania
Co bierzemy pod uwagę ?
•
•
•
•
•
poruszanie się po mieszkaniu
miejsce na urządzenia, np. w kuchni
szybka droga z garażu do kuchni
odpowiednia wielkość pokoi
....
analiza oparta na
przypadkach użycia
W ten sposób kształtuje
się architekturę
mieszkania
Przypadki użycia (use cases)
Konsultacja
z
architektem
(ekspertem)
Zalety zastosowania
„
„
„
„
„
Nie narzucają sposobu implementacji Æ pozwalają
zapomnieć o strukturze i architekturze systemu i
jego detalach technicznych na etapie analizy
Użytkownicy i eksperci mogą rozmawiać z
projektantami i programistami bez konieczności
analizowania nieistotnych szczegółów
Intuicyjna reprezentacja funkcjonalna systemu, nie
wprowadza komputerowego żargonu
Posiadają notację graficzną
Język zunifikowany, znany na całym świecie
Przypadki użycia (use cases)
Aktor
„
„
„
„
„
Używa systemu na wiele sposobów (przypadków użycia)
Jest sprawcą zdarzeń powodujących uruchomienie
przypadków użycia
Odbiera informacje wyprodukowane przez system
Jest modelem (obiektem), nie konkretną osobą –
reprezentuje rolę, jaką może grać konkretny użytkownik
Można tworzyć aktorów abstrakcyjnych (nadklasy)
Przypadki użycia (use cases)
Notacje
1. Graficzna
2. Tekstowa
Przypadki użycia (use cases)
Notacja graficzna - pojęcia
Przypadek użycia
Aktor
To unikalna nazwa, która opisuje
przypadek z punktu widzenia
głównego aktora
Reprezentuje zbiór ról odgrywanych
przez użytkowików przypadku użycia.
Zwykle jest to człowiek, maszyna, inny
system
Powinien mieć unikalną, jednoznaczną
nazwę
Przypadki użycia (use cases)
Notacja graficzna - pojęcia c.d.
Interakcje
Blok
ponownego
użycia
weryfikacja
klienta
Pokazuje związek między
przypadkiem użycia i aktorem
(środowiskiem zewnętrznym)
Pokazuje pewien fragment
działalności systemu, który jest
używany w kilku przypadkach
użycia. (Może być także oznaczony
jako samodzielny przypadek użycia).
Przypadki użycia (use cases)
Notacja graficzna - pojęcia c.d.
Asocjacje z blokiem
ponownego użycia
Nazwa systemu
wraz z granicami
systemu
Pokazuje związek przypadku użycia
z pewnym blokiem ponownego
użycia
Pokazuje granicę pomiędzy
systemem i jego otoczeniem
System obsługi klienta
...system informacyjny...
Przypadki użycia (use cases)
Przykład diagramu PU
(Siergiej)
wpłata pieniedzy
klient banku
wypłata pieniedzy
W operacjach wpłaty i wypłaty pieniędzy uczestniczą takze inni aktorzy,
np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujacy
wpłata pieniedzy
klient banku
wypłata pieniedzy
Przypadki użycia (use cases)
kasjer
Przykład diagramu PU 2
Automat
do sprzedaży
papierosów
uzupełnienie
towaru
zakup paczki
papierosów
klient
operacje
pieniężne
sporządzenie
raportów
operator
kontroler
Przypadki użycia (use cases)
<<rozszerza>> i <<używa>>
Relacje pomiędzy przypadkami użycia
rejestracja
klienta
używa
używa
przegląd
samochodu
rozszerza
umycie
samochodu
sprzedaż
samochodu
używa
rozszerza
naprawa
samochodu
rozszerza
używa: wskazuje na wspólny
fragment wielu przypadków
użycia, wyłączony “przed
nawias” (w tym sensie jest
“abstrakcyjny”, podobieństwo do
dziedziczenia)
rozszerza: strzałka prowadzi od
przypadku użycia, który czasami
(nie zawsze) rozszerza przypadki
użycia.
przyholowanie
samochodu
Przypadki użycia (use cases)
Powiązania w modelu PU
«uses» Modeluje sytuację kiedy przypadek (przypadki) użycia
wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok
ponownego użycia) na zasadzie podobnej do wywołania procedury.
«extends» Modeluje sytuację kiedy rozszerzający przypadek
użycia definiuje wspólne lub dobrze wyodrębnione akcje.
Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w
nim akcje plus niekiedy dodatkowo akcje określane przez przypadek
rozszerząjący. Jest on zwykle niekompletny.
Zmiany: «uses» «import», «extends» «extend»
Przypadki użycia (use cases)
Zależności czasowe między PU
Właściwie nie występuje w tym modelu nacisk na uwzględnianie zależności
czasowych między przypadkami użycia, tzn. nie interesuje nas wzajemna
kolejność przypadków użycia (co oznacza, że mogą być konstruowane w
dowolnej kolejności), ale jeśli ...
p1
<<używa>>
p2
Przebieg podstawowy - p1 (przypadek bazowy, podstawowy) zawsze używa p2,
a więc p1 musi być pierwsze w kolejności działania.
p1
<<rozszerza>>
p2
Przebieg opcjonalny - p1 (przypadek bazowy) jest czasami rozszerzane o p2,
tutaj też p1 musi być pierwsze w kolejności działania.
Przypadki użycia (use cases)
Przykład diagramu 3
(Bartek)
Automat do operacji bankowych
Baza
danych
banku
Klient
Administrator
systemu
Prowadzenie
konta klienta
Informowanie o
stanie konta klienta
Inicjalizacja
karty klienta
<<
uż
y
wa
>>
<<używa>>
<
ży
u
<
Przypadki użycia (use cases)
w
Weryfikacja karty
i kodu klienta
>
>
a
Notacja tekstowa
•Przypadek użycia może być wyspecyfikowany przez
opisanie ciągu zdarzeń w formie tekstu zrozumiałego
nawet dla laika.
•Wymagane informacje :
•Jak i kiedy zaczyna się i kończy
•Kiedy dochodzi do interakcji z aktorami
•Jakie obiekty są przekazywane
•Główny ciąg zdarzeń
Przypadki użycia (use cases)
Notacja tekstowa - przykład
Weryfikacja użytkownika
Główny ciąg zdarzeń :
Przypadek użycia zaczyna się, gdy system pyta klienta o PIN.
Klient może teraz wprowadzić hasło z klawiatury. Klient potwierdza
wprowadzone dane za pomocą klawisza „Wykonaj”. System sprawdza
poprawność PIN`u. Jeśli jest on poprawny, system informuje o tym. Na
tym kończy się przypadek użycia.
Nadzwyczajny ciąg zdarzeń :
Klient może w każdej chwili anulować transakcję, naciskając
klawisz „Stop”. Przypadek użycia wraca teraz do punktu początkowego.
Na koncie klienta nie zachodzą żadne zmiany
Przypadki użycia (use cases)
Przykład c.d.
Weryfikacja użytkownika
Nadzwyczajny ciąg zdarzeń :
Przed potwierdzeniem PIN`u Klient może w każdej chwili
wprowadzić go jeszcze raz.
Nadzwyczajny ciąg zdarzeń :
Gdy klient wprowadzi błędny PIN, przypadek użycia wraca do
punktu początkowego. Gdy zdarzy się to trzy razy z rzędu, system
anuluje całą transakcję i przez 60 sekund nie reaguje na żadne
działania klienta.
Przypadki użycia (use cases)
Rozbudowa modelu PU
wpłata
pieniedzy
wypłata
pieniedzy
(Siergiej)
wpłata
pieniedzy
kasjer
wypłata
pieniedzy
kasjer
używa
klient
banku
sprawdź
bilans
weź
pożyczkę
klient
banku
zarząd
banku
Przypadki użycia (use cases)
sprawdź
bilans
weź
pożyczkę
zarząd
banku
Charakterystyka PU
W późniejszej fazie przypadki użycia mogą być wyspecyfikowane
bardziej precyzyjnie przy pomocy notacji lub diagramów
obiektowych. Następną fazą w postępowaniu opartym na
przypadkach użycia jest rozpisanie ich w postaci scenariuszy.
edycja
programu
używa
kompilacja
programu
używa
Tworzenia przypadków
użycia jest
niezdeterminowane i
subiektywne. Na ogół
różni analitycy tworzą
różne modele.
wykonanie
programu
programista
drukowanie
pliku
Przypadki użycia (use cases)
użytkownik
Opis przypadków użycia
Co powinien zawierać opis przypadku użycia?
Opis przypadku użycia może być dowolnie rozbudowany, w
szczególności może zawierać następujące fragmenty:
1) Jak i kiedy przypadek użycia zaczyna się i kończy?
2) Opis interakcji przypadku użycia z aktorami,
włączając w to kiedy interakcja ma miejsce i co jest przesyłane.
3) Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych
w systemie, lub jak i kiedy zapamiętuje dane w systemie?
4) Wyjątki przy przepływie zdarzeń.
5) Jak i kiedy używane są pojęcia dziedziny problemowej?
Przypadki użycia (use cases)
Dokumentacja PU
1. Krótki opis przypadku użycia
2. Przepływ zdarzeń opisany nieformalnie
3. Asocjacje pomiędzy przypadkami użycia
4. Uczestniczące obiekty
5. Specjalne wymagania
(np. czas odpowiedzi, wydajność)
6. Obrazy interfejsu użytkownika
7. Ogólny pogląd na przypadki użycia
(powiązania w postaci diagramów)
8. Diagramy interakcji dla każdego aktora
Przypadki użycia (use cases)
Metoda oparta na PU
Metoda dotyczy analizy wymagań i opiera się na kilku krokach.
Jednocześnie jest budowany obiektowy model dziedziny.
Metoda jest oparta na ścisłej współpracy z przyszłym użytkownikiem.
Nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika.
Krok
Sporządzenie słownika pojęć
Udokumentowany w:
Słownik pojęć
Ustalenie aktorów
Ustalenie przypadków użycia
Dokument opisu aktorów
Opis każdego przypadku użycia:
* podział na nazwane części
* wyspecyfikowanie w szczegółach
* znalezienie wspólnych części
w różnych przypadkach użycia
Diagram przypadków użycia
Przypadki użycia (use cases)
Sporządzenie słownika pojęć
Polega na wyłowieniu wszystkich terminów z początkowych wymagań.
Słownik dotyczy dziedziny problemowej.
Terminy ze słownika powinny być normą przy opisie problemu,
sytuacji lub modelu.
Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny.
Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów,
aktywności, zdarzeń, itd.
Na co należy zwrócić uwagę przy kwalifikowaniu terminów
do słownika:
* na rzeczowniki: mogą one oznaczać aktorów lub obiekty
dziedziny problemowej
* na frazy opisujące funkcje, akcje, zachowanie się: mogą
one być podstawą wyróżnienia przypadków użycia.
Przypadki użycia (use cases)
Ustalenie aktorów
• Jaka grupa potrzebuje wspomagania ze strony systemu?
• Jacy użytkownicy są konieczni do tego, aby system?
•Funkcje należy rozbić na odnoszące się do
- dziedziny przedmiotowej (np. osoba rejestrująca) i
- wspomagania systemu (np. administrator systemu)
• Z jakiego sprzętu zewnętrznego (komputerów, sieci, itp.)
musi korzystać system aby realizować swoje funkcje.
Wyszukanie potencjalnych aktorów musi być powiązane z
ustaleniem granic systemu, tj. odrzucenia obszarów
dziedziny problemowej, którymi system nie zajmuje się.
Przypadki użycia (use cases)
Ustalenie aktorów c.d.
Po wyszukaniu aktorów, należy ustalić:
- czy jest to aktor konkretny (Jan Kowalski),
czy też określenie roli (magazynier)
- nazwę dla każdego aktora/roli
- zakresy znaczeniowe dla poszczególnych nazw aktorów
oraz relacje pomiędzy zakresami
(sekretarka → pracownik administracji → pracownik → dowolna osoba).
Niekiedy warto ustalić hierarchię dziedziczenia dla aktorów.
- opisać relacje pomiędzy konkretnymi użytkownikami i aktorami
- czy użytkownik może łączyć funkcje kilku aktorów i jakich
Przypadki użycia (use cases)
Analiza aktorów
• Jakie jest główne zadanie dla każdego aktora?
• Czy aktor będzie czytał/pisał/zmieniał informację w systemie?
• Czy aktor ma informować system o zmianach na zewnątrz?
Użytkownik
Aktor
Może grać rolę
Jest związany z:
Przypadek użycia
Jan Kowalski
Administrator systemu
Przeładowanie systemu
Adam Malina
Pracownik
Wejście z kartą i kodem
Gość
Osoba informowana
Informacja ogólna
Konkretny klient
Klient
Wypłata z konta
Przypadki użycia (use cases)
Ustalenie przypadków użycia
Dla każdego aktora, znajdź zadania i funkcje, które powinien wykonywać w
związku z jego działalnością w zakresie dziedziny przedmiotowej jak i systemu
informacyjnego.
Staraj się powiązać w jeden przypadek użycia zespół funkcji i zadań
wspólnie realizujących ten sam cel. Unikaj rozbicia jednego przypadku użycia na
wiele pod-przypadków, o ile każdy z nich realizuje cel cząstkowy, który musi być
uzupełniony przez inne funkcje lub zadania.
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.
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ą
Przypadki użycia (use cases)
być uogólnione.
Specyfikacja każdego PU
Wyodrębnij “przypadki bazowe”, tj. takie, które stanowią istotę zadania lub
funkcji, są normalnym, standardowym użyciem. Pomiń czynności skrajne,
wyjątkowe, uzupełniające lub opcyjne.
Nazwij te “przypadki bazowe”; nazwy powinny być proste i zrozumiałe. Ustal
wzajemne powiązanie “przypadków bazowych”, poprzez ustalenie ich sekwencji,
alternatywy, zależności, związku przyczyna-skutek, itd.
Dodaj zachowanie skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal
powiązanie “przypadków bazowych” z tego rodzaju zachowaniem. Może ono byc
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 wielokrotnego użycia.
Struktura nie może być zbyt duża i złożona.
Staraj się wyizolować bloki wielokrotnego użycia. Przeanalizuj podobieństwo
nazw przypadków użycia, podobieństwo nazw i zachowania bloków występujących
w ich specyfikacji. Wydzielenie bloku wielokrotnego użycia może być powiązane z
określeniem nieco bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do
Przypadki użycia (use cases)
istniejącej funkcji.