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.

System tworzy sprawę likwidacji szkody i nadaje jej

unikalny numer identyfikacyjny.

Przyjmujący wprowadza dane określające charakter

szkody, obejmujące opis wypadku i opis uszkodzeń,

oraz podpisuje dokument zgłoszenia.

System przypisuje likwidatora szkody, który ocenia

zasadność zgłoszenia i prowadzi postępowanie

odszkodowawcze.

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»

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

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>>

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:

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>>

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»

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ę

zdalnie

wypozycz ksiazke

«include»

«extend»

uc obsługa realizacji szkoleń

System obsługi szkoleń

Koordynator szkoleń

(from Aktorzy)

Trener

(from Aktorzy)