Model przypadków użycia
Model przypadków użycia
Model przypadków użycia
•
Wymagania użytkowników systemu informacyjnego
można przedstawić w postaci listy zdań, które chcą
oni za pomocą tego systemu wykonać. Każde z tych
zadań można opisać podając kolejność działań, w toku
których użytkownik wybierze zadanie poda dane
niezbędne do jego realizacji i odbierze potrzebne mu
wyniki. W ten sposób opis wymagań przyjmie postać
opisu wszystkich sposobów używania systemu przez
użytkowników.
•
Przykładowo zadania wykonywane przez firmę
ubezpieczeniową obejmują zawarcie ubezpieczenia
OC lub AC oraz wypłacenie odszkodowania, nazwane
likwidacją szkody.
Przykład – firma
ubezpieczeniowa
• Zawarcie ubezpieczenia jest wykonywane na zlecenie
klienta, któremu przynosi korzyść w postaci ochrony
przed odpowiedzialnością cywilną lub rozbiciem
własnego samochodu. Wykonanie zadania obejmuje
wypełnienie danych na formularzu, dołączenie kopi
dokumentów samochodu, opłacenie składki i odebranie
polisy ubezpieczeniowej.
• Likwidacja szkody następuje na wniosek klienta,
któremu przynosi korzyść w postaci zwrotu
poniesionych kosztów. Wykonanie zadania obejmuje
wypełnienie formularza zgłoszenia szkody,
przedstawienie polisy ubezpieczeniowej, ocenienie
przez firmę zasadności roszczenia i wartości szkody
oraz dokonanie przelewu na konto klienta.
Model przypadków użycia
• Graficzną reprezentacją modelu jest
diagram przypadków użycia (use case
diagram), którego podstawowymi
elementami są ikony aktorów, owale
reprezentujące przypadki użycia oraz linie
przedstawiające zachodzące między nimi
relacje. Istnienie relacji łączącej aktora z
przypadkiem użycia wskazuje na
zaangażowanie tego aktora w realizację
danego przypadku.
uc Use Case View
System ubezpieczeń
Klient
Likwidator
System bankowy
zawarcie
ubezpieczenia
wypłata
odszkodowań
likwidacja szkody
Diagram przypadków użycia firmy
ubezpieczeniowej
Aktora inicjującego wykonanie przypadku użycia
można wyróżnić dodatkową strzałką umieszczoną na
końcu linii relacji.
Aktorzy diagramu PU modelują zewnętrzne obiekty
współpracujące z budowanym systemem.
Diagram przypadków użycia
Diagram przypadków użycia (Use
Case Diagram) ukazuje
system z
punktu widzenia użytkownika
.
Diagram przypadków
użycia
• Diagram przypadków użycia (ang. Use Case
Diagram) jest diagramem, który
przedstawia
funkcjonalność systemu wraz z jego
otoczeniem
• Diagramy przypadków użycia pozwalają na
graficzne zaprezentowanie własności
systemu tak, jak są one widziane po stronie
użytkownika
• Diagramy przypadków użycia służą do
zobrazowania usług, jakie są widoczne z
zewnątrz systemu
Diagramy przypadków
użycia
• specyfikują wymagania stawiane
systemowi
• obrazują zachowanie systemu
• modelują otoczenie systemu
• nie definiują sposobu implementacji
systemu
• opisują jedynie najważniejsze aspekty
zachowania systemu
• nie są przesadnie szczegółowe
• są platformą do komunikacji analityka z
klientem
Diagram przypadków użycia
Kluczowymi elementami są
:
• aktorzy (actor)
• przypadki użycia (use case)
• związki (association)
Dodatkowo
diagram może zwierać:
• notatki (note)
• ograniczenia (constraints)
• pakiety (packages)
Aktor
• Aktor (ang. actor) jest
funkcją, jaką pełni
użytkownik w stosunku do systemu oraz
przypadków użycia
.
• Aktor reprezentuje
spójny zbiór ról, które
są odgrywane przez użytkowników
przypadku użycia w czasie interakcji z
tym przypadkiem
.
• Aktorem może być
człowiek, urządzenie,
inny system lub czas
.
• Aktor nie musi być fizycznym obiektem.
Istotne by pełnił określoną funkcję wobec
systemu i przypadku użycia, którego używa.
Aktor
Aktor to użytkownik lub inny system,
który wchodzi w interakcję z naszym
systemem.
Najczęściej
używany symbol
Aktor
• Aktorzy stanowią otoczenie systemu
(nie są częścią systemu)
• Aktor może aktywnie wymieniać
informacje z systemem
(dostarczać
informacje i pobierać)
• Aktor może wywoływać akcje w
systemie
• Aktorami mogą być
:
człowiek
urządzenie
inny system
Aktor
Aktor reprezentuje rolę w jakiej
człowiek, inny system bądź
urządzenie może się wcielić w
interakcji z naszym systemem.
Jeden
Kowalski w
wielu rolach
Aktor
Aktorzy mogą występować w zależności
uogólnienie (generalization). Potomek
dziedziczy całe zachowanie i znacznie po
przodku.
Klient indywidualny i klient instytucjonalny
są szczególnym
rodzajem
klienta.
Generalizacja
Student
Użytkowni
k
potomek
przodek
Grot strzałki wskazuje na przodka (klasę ogólną)
Związek generalizacji
to związek pomiędzy
elementem ogólnym (nadklasa lub przodek) a
specyficznym jego rodzajem zwanym podklasą lub
potomkiem. Element specyficzny jest całkowicie
zgodny z elementem ogólnym i zawiera dodatkową
informację. Egzemplarz elementu specyficznego może
być użyty wszędzie tam, gdzie dopuszcza się
egzemplarz elementu ogólnego.
Potomek zawsze może zastąpić
przodka
uc aktorzy
Wypożyczający
(from Use Case View)
Student
Pracownik naukowy
Aktor
Pojaz
d
Uogólnienie
Człowiek
ogólnie
szczególnie
Przypadek użycia
• Przypadek użycia (PU) jest
graficzną
reprezentacją wymagań
funkcjonalnych
• Definiuje zachowanie systemu bez
informowania o wewnętrznej strukturze
i narzucania sposobu implementacji
• Przypadek użycia pozwala na
zdefiniowanie przyszłego,
spodziewanego zachowania systemu
Dodaj słuchacza
Przypadek użycia
• Kwant funkcjonalności systemu
dostarczający aktorowi usług o
mierzalnej wartości (I. Jacobson).
• Czynność, której wykonanie
bezpośrednio świadczy o
efektywności pracy
• Nazwana lub dobrze określona
interakcja pomiędzy użytkownikiem
a systemem komputerowym
Przypadek użycia
• Przypadek użycia musi być w
interakcji, chociaż z jednym
aktorem. Wyjątek stanowi sytuacja,
gdy przypadek użycia jest połączony
z innym przypadkiem użycia
związkiem rozszerzenie lub
zawierania.
• Przypadek użycia to
zbiór
scenariuszy powiązanych ze sobą
wspólnym celem użytkownika
.
Sprawdź ocenę
Przypadek użycia
Przypadek użycia opisuje, co system
robi, lecz nie określa, jak to robi.
Sprawdź
stan
konta
Przypadek użycia
Przypadek użycia to
opis zbioru
akcji wykonywanych przez system w
celu dostarczenia aktorowi wyniku
.
W UML przypadek użycia jest
przedstawiony w postaci elipsy z
nazwą po środku.
Sprawdź
stan
konta
Klient
banku
Przypadek użycia
Elementy żyjące wewnątrz systemu
(przypadki użycia) są odpowiedzialne
za wykonanie działań, których
elementy zewnętrzne (aktorzy)
oczekują od systemu.
Nazwa przypadku użycia musi być
czynnością.
Przypadek użycia
Budując model należy pamiętać o
oddzieleniu pojęć – tego, co dotyczy
pracy systemu, od tego, co dotyczy
jego realizacji.
Informacyjna zawartość DPU jest dość
uboga i nie opisuje wystarczająco
dokładnie sposobu używania systemu
przez użytkowników. Dlatego
podstawowym środkiem
dokumentowania modelu jest tekstowy
zapis scenariuszy, opisujących krok po
kroku sposób wykonania wszystkich
przypadków użycia.
PU przykład – scenariusz
główny
Likwidacja szkody
1.
Przyjmujący rejestruje zgłoszenie szkody w systemie.
Zgłoszenie obejmuje numer polisy, dane
zgłaszającego, datę wypadku i datę zgłoszenia.
2.
System tworzy sprawę likwidacji szkody i nadaje jej
unikalny numer identyfikacyjny.
3.
Przyjmujący wprowadza dane określające charakter
szkody, obejmujące opis wypadku i opis uszkodzeń,
oraz podpisuje dokument zgłoszenia.
4.
System przypisuje likwidatora szkody, który ocenia
zasadność zgłoszenia i prowadzi postępowanie
odszkodowawcze.
5.
Likwidator oblicza wartość odszkodowania i
przekazuje zlecenie wypłaty do działu księgowości.
PU przykład – scenariusz
alternatywny
Likwidacja szkody – duplikat zgłoszenia
1. Jak w scenariuszu głównym.
2. System powiadamia o istniejącym
zgłoszeniu i odmawia utworzenia sprawy.
Likwidacja szkody – nieważna polisa
1–5. Jak w scenariuszu głównym.
6. Likwidator powiadamia klienta o odmowie
odszkodowania i zamyka sprawę
PU – poziomy abstrakcji
• Pojedynczy PU reprezentuje zbiór scenariuszy, w których
istnieje scenariusz główny opisujący typowy sposób
postępowania prowadzący do osiągnięcia celu użytkownika,
oraz scenariusze alternatywne, opisujące sposoby
postępowania w razie niemożności wykonania scenariusza
głównego.
• Modelowanie wymagań za pomocą PU może przebiegać na
różnych poziomach abstrakcji. Przypadki użycia Zawarcie
ubezpieczenia i Likwidacja szkody tworzą całościowy opis
sposobów obsługiwania klientów przez przedsiębiorstwo
ubezpieczeniowe. Taki model jest bardzo użyteczny w
początkowym stadium projektu. Dalsza analiza reguł
działania i wymagań użytkownika może prowadzić do
wyodrębnienia przypadków użycia opisujących sposoby
używania systemu do poszczególnych kroków obsługi klienta
przez pracowników firmy takich jak: Rejestracja dokumentu,
Rejestracja zgłoszenia szkody, Utworzenie sprawy szkody,
Wycena wartości szkody, Obliczanie odszkodowania itp.
Związki
Związki w diagramach przypadków
użycia
:
• powiązania
(tylko między
aktorem a przypadkiem użycia)
• uogólnienia
• zawierania – include
• rozszerzenia - extend
Związki
Związek zawierania
stosuje się w
celu uniknięcia wielokrotnego
opisywania tego samego ciągu
zdarzeń.
Przyjmij towar...
zawsze zawiera
Czytaj kod...
<< include >>
Związek zawierania
Bazowy
PU
Zawierany
PU
includ
e
Zobacz
prezentacj
ę
Wysłuchaj
wykładu
includ
e
Związek zawierania (ang. Include)
polega na
tym, że bazowy przypadek użycia rozszerza swoją
funkcjonalność o zachowanie innego przypadku
użycia. Zawierany przypadek użycia nie jest
autonomiczny.
uc Use Case View
przeanalizuj ryzyko
określ wartość
wyceń kontrakt
«include»
«include»
Do relacji zawierania dochodzi wtedy, gdy kilka
przypadków użycia ma wspólną sekwencję podobnych
kroków, której nie warto ciągle kopiować z jednego
przypadku do drugiego. Przykładowo „przeanalizuj
ryzyko” i „wyceń kontrakt” wymagają, aby określić
wartość kontraktu. Opisanie określenia wartości
kontraktu wymaga sporo pracy, stąd należy utworzyć
oddzielny przypadek użycia „określ wartość kontraktu” i
odwołać się do niego z innych PU.
Zawieranie
Uogólnienie
uc związek uogolnienia
zarejestruj
transakcje
limit przekroczony
Uogólnienia używa się wówczas, gdy dany przypadek użycia
jest podobny do innego, ale jest nieco obszerniejszy. Jest to
jeszcze jeden ze sposobów uchwycenia scenariuszy
alternatywnych. W przykładzie podstawowym PU jest
„zarejestruj transakcję”. Jest to pomyślany przypadek użycia
systemu, w sytuacji gdy wszystko się powiodło. Coś mogło
jednak przeszkodzić pomyślnej rejestracji transakcji, np.
przekroczenie limitu, który biuro maklerskie ustaliło dla
konkretnego kontrahenta. W takiej sytuacji nie wykonuje się
typowych kroków związanych z tym PU, lecz alternatywny
przypadek użycia. Specjalistyczny PU może przesłonić
dowolną część podstawowego PU, ale zawsze powinien
dotyczyć osiągnięcia tego samego celu użytkownika co
podstawowy PU.
Relacja rozszerzenia
Jest ta relacja podobna do uogólnienia, jednak bardziej
formalna. Rozszerzenie PU może wzbogacić go o dodatkowe
zachowania, ale w takiej sytuacji podstawowy PU musi
określić pewne punkty rozszerzenia, a rozszerzający PU
może dodać nowe zachowania tylko w tych punktach.
Przypadek użycia może mieć wiele punktów rozszerzeń, a
rozszerzający PU może rozszerzać podstawowy PU w kilku z
tych punktów.
PU pożycz książkę można podzielić na zwykły PU, w którym
użytkownik może pożyczyć książkę, i wyjątkowy PU, w
którym użytkownik nie może jej pożyczyć, ponieważ
wypożyczył już maksymalną dopuszczalną liczbę książek.
uc zwiazek extend
pozycz ksiazke
odmowa pozyczki
«extend»
Związki
Związek rozszerzenia
służy do
modelowania fragmentów przypadku
użycia postrzeganych przez
użytkownika jako
opcjonalne
zachowanie systemu
.
Ekspresowa... opcjonalnie rozszerza
Przesyłkę...
<< extend >>
Bazowy
PU
Rozszerzający
PU
exten
d
Wykonaj
ćwiczenie
Wysłuchaj
wykładu
exten
d
Związek rozszerzania (ang. Extend)
wskazuje,
że dany przypadek użycia opcjonalnie rozszerza
funkcjonalność bazowego przypadku użycia.
Funkcjonalność bazowego przypadku użycia jest
rozszerzana o inny przypadek użycia po
spełnieniu określonego warunku.
Związek rozszerzania
Warunek: {standard
nauczania wymaga
ćwiczeń}
Student
Użytkowni
k
Związek zawierania i rozszerzania
Sprawdź
ocenę
Zobacz
zaległości
finansowe
Wyświetl
wszystkie
oceny
extend
includ
e
Extension points
Extension Points pozwalają na
dokładniejsze określenie jakie
rozszerzające przypadki użycia mają
być wywołane.
Punkt rozszerzania
Punkt rozszerzania
(extension points)
wskazuje na to
miejsce w
zachowaniu
(scenariuszu)
przypadku użycia,
które jest
rozszerzone o inny
przypadek użycia za
pomocą związku
rozszerzenia.
Przelicz kwotę
zamówienia
Złóż zamówienie
Extension points
wymagana zmiana
waluty
extend
Extension points
Rozszerzający
przypadek
użycia
Warunek
rozszerzen
ia
Miejsce
rozszerzenia
Przykład
od Analysis View
Moduł rezerwacji
rezerwacja
rezerwacja
czasopisma
rezerwacja ksiązki
czytelnik
wyszukanie
powiadomienie
«include»
«extend»
Uogólnienie
Zawieranie
Rozszerzenie
Zasady (reguły) dla PU
• Gdy trzeba
powtórzyć coś w kilku
różnych PU
, a jednocześnie chce się
uniknąć powtórzyć, należy używać
relacji
zawierania
.
• Gdy trzeba
opisać warianty typowego
postępowania przy zachowaniu opisu
nieformalnego
, należy używać
relacji
uogólnienia
.
• Gdy trzeba
opisać warianty typowego
postępowania
, ale jest potrzebny
bardziej
formalny opis ze zdefiniowaniem
punktów rozszerzeń
w przypadku
podstawowym, należy używać
relacji
rozszerzania
.
Pakiety
Pakiety pomagają
dzielić usługi
(przypadki użycia)
logicznie w
systemie.
Diagram przypadków użycia
Siec telefonii komorkowej
Uzytkownik
Z ainicjuj
polaczenie
Z aakceptuj
polaczenie
Uzyj programu
wybierajacego
Z ainicjuj
telekonferencje
Z aakceptuj
dodatkowe
polaczenie
<<extend>>
<<extend>>
Telefon komorkowy
Granica
systemu
Diagram przypadków użycia
Dobre rady przy budowaniu diagramu:
• nazwij diagram zgodnie z
przeznaczeniem
• tak rozmieść przypadku użycia i
aktorów żeby zminimalizować liczbę
przecinających się związków
• poukładaj przypadki użycia blisko
siebie, które są podobne pojęciowo
• korzystaj z notatek
• nie musisz przedstawiać wszystkich
przypadków użycia na jednym
diagramie
Diagram przypadków użycia
• Przypadki użycia
służą do
modelowania oczekiwanego
zachowania systemu
(bez zgłębiania
sposobu implementacji systemu)
.
• Dobrze zbudowane przypadki użycia
reprezentują jedynie najważniejsze
aspekty zachowania systemu
(nie są
przesadnie szczególne ani zbyt ogólne)
.
Proces tworzenia DPU
• Proces tworzenia diagramu przypadków
użycia jest procesem iteracyjnym
składającym się z takich etapów jak:
– Identyfikacji aktorów
– Opcjonalnemu opracowaniu diagramu
kontekstowego
– Identyfikacji przypadków użycia
– Opracowaniu związków – w szczególności asocjacji
– Wykorzystaniu wszystkich kategorii
zaawansowanych do opracowania diagramów
przypadków użycia
– Udokumentowaniu przypadków użycia z
wykorzystaniem szablonów
Szablon dokumentacji PU
Nazwa
Pełna nazwa przypadku użycia
Numer PU
Numer identyfikacyjny przypadku użycia
Twórca
Dane twórcy PU (nazwisko, imię, stanowisko)
Poziom
ważności
Określenie poziomu ważności PU z perspektywy użytkownika np.
niski, średni, wysoki
Typ przypadku Określenie typu PU z punktu widzenia jego złożoności oraz ważności
dla zaspokojenia potrzeb użytkownika ogólny/szczegółowy;
niezbędny/istotny/przeciętnie istotny
Aktorzy
Lista aktorów będących w związku z przypadkiem użycia
Krótki opis
Krótka ogólna charakterystyka przypadku użycia
Warunki
wstępne
Charakterystyka koniecznych warunków inicjujących PU
Warunki
końcowe
Charakterystyka stanu systemu po realizacji PU
Główny
przepływ
zdarzeń
Wypunktowana i scharakteryzowana lista przypadków zdarzeń
zachodzących podczas PU; scenariusz główny
Alternatywne
przepływy
zdarzeń
Wypunktowana i scharakteryzowana lista możliwych, alternatywnych
przepływów zdarzeń PU
Specjalne
wymagania
Wypunktowana i scharakteryzowana lista dodatkowych
zidentyfikowanych wymagań niefunkcjonalnych, które mogą być
istotne podczas projektowania czy kodowania
Notatki
Lista wszelkich komentarzy dotyczących PU
Dokumentacja przypadku użycia {Anuluj
rezerwację}
Nazwa przypadku użycia:
Anuluj rezerwację
Numer:
5
Twórca:
Anna Krotoszyńska - projektant
Aktorzy:
Recepcjonista, Kierownik recepcji
Krótki opis:
Anulowanie istniejącej rezerwacji pokoju lub apartamentu
Waruki wstępne:
Co najmniej jeden pokój lub apartament hotelowy musi być
zarezerwowany
Warunki końcowe:
System odnotowuje pokój lub (i) apartament jako dostępny
Główny przepływ zdarzeń
1. Recepcjonista weryfikuje rezerwacje, uruchamiając funkcję
„Rezerwacje”
2. System wyświetla okno z informacjami o rezerwacjach
3. Pracownik recepcji zaznacza rezerwacje do anulowania i
uruchamia funkcje „Anuluj rezerwacje”
4. System wyświetla komunikat „Czy anulować zaznaczone
rezerwacje?”
5. Pracownik recepcji potwierdza operację anulowania
zaznaczonych rezerwacji
6. System potwierdza wykonanie operacji komunikatem
„Anulowano wybrane rezerwacje” i odświeża ekran monitora
Alternatywne przepływy
danych
2a. System wyświetla komunikat „Brak rezerwacji”
3a. Pracownik recepcji rezygnuje z anulowania rezerwacji
3b. Jeżeli podczas rezerwacji podany został adres e-mail, pracownik
może wysłać do klienta informację o anulowaniu rezerwacji
Specjalne wymagania
1. Wysoka niezawodność systemu
2.Czas przetwarzania operacji anulowania rezerwacji nie może
przekroczyć 5 sekund
Notatki
Brak
Diagram przypadków użycia
Siec telefonii komorkowej
Uzytkownik
Z ainicjuj
polaczenie
Z aakceptuj
polaczenie
Uzyj programu
wybierajacego
Z ainicjuj
telekonferencje
Z aakceptuj
dodatkowe
polaczenie
<<extend>>
<<extend>>
Telefon komorkowy
Diagram przypadków użycia
uc Use Case View
System maklerski
Kierownik sali
System księgowy
ustal limity
przeanalizuj ryzyko
wyceń kontrakt
zarejestruj
transakcje
limit przekroczony
zaktualizuj rachunki
określ wartość
Sprzedawca
Makler
«include»
«include»
Niektóre przypadki użycia dla systemu maklerskiego
uc Use Case View
Zarządzający zbiorami
Wypożyczający
System biblioteki
głównej
wprowadź nowy
egzemplarz
dodaj istniejący
egzemplarz
wyszukaj książkę
rejestruj rezerwację
rejestruj rezerwację
zdalnie
wypozycz ksiazke
«include»
«include»
«extend»
uc obsługa realizacji szkoleń
System obsługi szkoleń
Koordynator szkoleń
(from Aktorzy)
Trener
(from Aktorzy)
(from Obsługa realizacji szkoleń)
Rejestruj
Trenera
(from Obsługa realizacji szkoleń)
Przejrzyj moje
szkolenia
(from Obsługa realizacji szkoleń)
Przypisz zasoby
do szkolenia
(from Obsługa realizacji szkoleń)
Oceń
zrealizowane
szkolenie
(from Obsługa realizacji szkoleń)
Przypisz Trenera
do szkolenia
Wprowadź
dane
uczestnika
(from Obsługa realizacji szkoleń)
Przejrzyj listę
uczestników
przypisanych do
szkolenia
Prezentuj
informację o
szkoleniu
Prezentuj
informacje o
szkoleniu
zrealizowanym
Prezentuj
informacje o
szkoleniu
otwartym
Przypisz
uczestnika do
szkolenia
Abstrakcyjny przypadek
użycia. Nie jest
implementowany w
systemie niemniej
jednak jego istnienie
można zaznaczyć w
modelu
«include»
«extend»
«include»
«extend»
«include»
«include»
«include»
uc Use Case View
System wspierający pracę kancelarii prawniczej
Prawnik
Szef kancelarii
anuluj sprawę
rejestruj sprawę
rejestruj rozprawę
przydziel prawnika
do sprawy
Podsystem czasu
usuń sprawę
podaj listę spraw
zakończonych
sukcesem
sprawdź czy
prawnik jest wolny
odsuń prawnika od
sprawy
«extend»
«include»
Kiedy stosować PU
systemu
• Podstawowe narzędzie w uchwyceniu
wymagań systemu oraz w planowaniu
i zarządzaniu iteracyjnym projektem
tworzenia oprogramowania.
• PU reprezentują spojrzenie z
zewnątrz na system i dlatego nie
istnieją korelacje między nimi a
klasami wewnątrz systemu.
Ćwiczenie
Automat do sprzedaży napojów
Automat sprzedaje kawę, herbatę i czekoladę. Do
kawy i herbaty można dodatkowo zażyczyć sobie
cukier. Do herbaty opcjonalnie można zamówić
cytrynę, a do kawy śmietankę.
Spragniony klient wrzuca monety do automatu i
wybiera napój z opcjonalnymi dodatkami. Kiedy
zakończy komponowanie napoju naciska przycisk
„Wydaj napój” i czeka na napój. Do momentu
wciśnięcia przycisku wydającego napój klient może
zrezygnować z zakupu wciskając przycisk „Zwrot
monet”, pieniądze zostaną zwrócone.
Ćwiczenie