Przypadki użycia ( use cases)
.Po co są przypadki użycia ?
.Próby definicji
.Podstawowe pojęcia
.Notacje
.Relacje
.Dokumentacja
.Kroki metody
.Przykłady
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.
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 w analizie
Technologie
Koncepcja
zastosowania
Eksperci
Użytkownicy
Model
dziedziny
mocny wpływ
słaby wpływ
Potrzeby
Pomysły
Doświadczenie
w dziedzinie
przedmiotowej
Przypadki
użycia
Model
zastosowania
Kompletny
model
analizy
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 Projektowanie mieszkania
• 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
Konsultacja
z
architektem
(ekspertem)
Co bierzemy pod uwagÄ™ ?
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
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)
Notacje
1. Graficzna
2. Tekstowa
Notacja graficzna - pojęcia
Aktor
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Ä™
Przypadek użycia To unikalna nazwa, która opisuje
przypadek z punktu widzenia
głównego aktora
Notacja graficzna - pojęcia c.d.
Blok
ponownego
użycia
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).
Interakcje Pokazuje związek między
przypadkiem użycia i aktorem
(środowiskiem zewnętrznym)
weryfikacja
klienta
Notacja graficzna - pojęcia c.d.
Nazwa systemu
wraz z granicami
systemu Pokazuje granicę pomiędzy
systemem i jego otoczeniem
Asocjacje z blokiem
ponownego użycia Pokazuje związek przypadku użycia
z pewnym blokiem ponownego
użycia
System obsługi klienta
...system informacyjny...
Przykład diagramu PU (Siergiej)
wpłata pieniedzy
wypłata pieniedzy
wpłata pieniedzy
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
kasjer
klient banku
klient banku
Przykład diagramu PU 2
klient operator
Automat
do sprzedaży
papierosów
zakup paczki
papierosów
uzupełnienie
towaru
operacje
pieniężne
sporzÄ…dzenie
raportów
kontroler
<> i <>
Relacje pomiędzy przypadkami użycia
naprawa
samochodu
przeglÄ…d
samochodu
rejestracja
klienta
umycie
samochodu
rozszerza
przyholowanie
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.
sprzedaż
samochodu
używa
używa
używa
rozszerza
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
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 ...
Przebieg podstawowy - p1 (przypadek bazowy, podstawowy) zawsze używa p2,
a więc p1 musi być pierwsze w kolejności działania.
Przebieg opcjonalny - p1 (przypadek bazowy) jest czasami rozszerzane o p2,
tutaj też p1 musi być pierwsze w kolejności działania.
p1 p2
<>
p1 p2
<>
Przykład diagramu 3 (Bartek)
Baza
danych
banku
Klient
Administrator
systemu
Prowadzenie
konta klienta
Informowanie o
stanie konta klienta
Inicjalizacja
karty klienta
Weryfikacja karty
i kodu klienta
Automat do operacji bankowych
<>
<>
<>
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Å„
Notacja tekstowa - przykład
Weryfikacja użytkownika
Główny ciąg zdarzeń :
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
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.
Przykład c.d.
Weryfikacja użytkownika
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.
Nadzwyczajny ciąg zdarzeń :
Przed potwierdzeniem PIN`u Klient może w każdej chwili
wprowadzić go jeszcze raz.
Rozbudowa modelu PU (Siergiej)
wpłata
pieniedzy
wypłata
pieniedzy
kasjer
sprawdź
bilans
weź
pożyczkę zarząd
banku
wpłata
pieniedzy
wypłata
pieniedzy
kasjer
sprawdź
bilans
weź
pożyczkę zarząd
banku
używa
klient
banku
klient
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
kompilacja
programu
Tworzenia przypadków
użycia jest
niezdeterminowane i
subiektywne. Na ogół
różni analitycy tworzą
różne modele.
wykonanie
programu
drukowanie
pliku
programista użytkownik
używa
używa
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?
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
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.
Udokumentowany w:
Słownik pojęć
Ustalenie aktorów
Ustalenie przypadków użycia Dokument opisu aktorów
Diagram przypadków użycia
Krok
Sporządzenie słownika pojęć
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
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.
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ę.
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
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 Przypadek użycia
Może grać rolę Jest związany z:
Jan Kowalski
Adam Malina
Gość
Konkretny klient
Osoba informowana
Klient
Przeładowanie systemu
Wejście z kartą i kodem
Informacja ogólna
Wypłata z konta
Administrator systemu
Pracownik
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ą
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
istniejÄ…cej funkcji.