Przypadek użycia

Transkrypt

Przypadek użycia
Model przypadków użycia
Anna Bobkowska
ykładu
w
o
d
e
z
cnic
TI PG.
o
E
m
o
le
p
ia
z
ły
d
Materia
ia na Wy
n
a
w
ładzie.
o
k
y
m
w
a
r
a
g
n
o
i
r
rii Op
obecnośc elu oraz ich
je
u
z Inżynie
p
ę
t
s
a nie za
innym c
Ich lektur nie materiałów w
nione.
o
r
b
a
a
t
z
s
t
y
s
z
je
Wykor
chnianie
e
z
s
w
o
p
roz
slajd 1
Diagram przypadków użycia
• Pokazuje:
– funkcjonalność systemu widzianą
od zewnątrz, zbiór usług
• Identyfikowani są:
– aktorzy, przypadki użycia oraz
powiazania i związki między nimi
Przypadek użycia 1
Aktor 2
Aktor 1
Przypadek użycia 2
• Określa:
– granice systemu:
– użytkowników i inne systemy
współpracujące z systemem - aktorzy
– funkcjonalność realizowana przez
system: przypadki użycia
Przypadek użycia 3
System
Model przypadków użycia można rozbudowywać poprzez dodawanie
nowych aktorów, nowych przypadków użycia oraz nowych powiązań
slajd 2
Definicje
• Model przypadków użycia - funkcjonalność z punktu widzenia
użytkownika, system widziany jako „czarna skrzynka”.
• Przypadek użycia (ang. use case) - (spójna) jednostka
funkcjonalności dostarczana przez system, która jest
realizowana jako ciąg interakcji pomiędzy aktorem a
systemem.
• Aktor (ang. actor) - abstrakcyjny użytkownik systemu,
reprezentujący grupę rzeczywistych użytkowników o
podobnych funkcjach i sposobie komunikacji z systemem;
najczęściej aktor jest sprawcą zdarzenia powodującego
uruchomienie przypadku użycia.
• Powiązanie Aktor - Przypadek użycia (ang. association) usługa określona przez przypadek użycia jest dostępna dla
aktora, aktor i system komunikują się podczas realizacji
przypadku użycia.
• System lub obiekt (ang. Subject)
posiada przypadki użycia
slajd 3
Klasyfikacja aktorów
• Aktor główny - korzysta z podstawowych funkcji systemu
• Aktor drugorzędny - korzysta głównie z funkcji służących do
realizacji zadań pomocniczych (np. administrowania i pielęgnacji
systemu)
• Aktor aktywny - inicjuje przypadek użycia
• Aktor pasywny - nie inicjuje przypadku użycia, lecz tylko w nim
uczestniczy
• Aktor ożywiony – reprezentacja grupy ludzi
• Aktor nieożywiony – system urządzenie
• Aktor zewnętrzny – domyślnie
• Aktor wewnętrzny – w modelowaniu biznesowym
slajd 4
Identyfikacja aktorów
•
•
•
•
Kto komunikuje się z systemem ?
Kto będzie korzystał z funkcji systemu ?
Kto będzie system pielęgnował ?
Jakie urządzenia system obsługuje ?
(aktorzy nieożywieni)
• Z jakimi innymi systemami system się
komunikuje?
(aktorzy będący innymi systemami)
• Kto lub co jest zainteresowane wynikami
pracy systemu ?
slajd 5
Identyfikacja przypadków użycia
• Dla każdego aktora odpowiedz na pytania:
– jakiej funkcji aktor wymaga od systemu: czy aktor musi pamiętać, tworzyć,
usuwać, modyfikować informacje w systemie
– czy aktor ma być powiadamiany o zdarzeniach w systemie, i na odwrót
• Rozważ, jakie są wejścia i wyjścia systemu
• Staraj się powiązać w jeden przypadek użycia zespół funkcji wspólnie
realizujących ten sam cel
• Opisz przypadki użycia w języku naturalnym, według określonego
szablonu
• Zobrazuj aktorów i przypadki użycia na diagramie przypadków użycia
• Przeanalizuj powiązania pomiędzy aktorami, pomiędzy przypadkami
użyciaoraz pomiędzy aktorami i przypadkami użycia
slajd 6
Przypadki użycia biznesowe i programowe
‘BIZNESOWE’
• Cel:
pokazanie roli i usług dostarczanych
przez organizację
• Granica:
Usługi wykonywane przez ludzi
mogą być wewnątrz systemu
• Aktorzy wewnętrzni – użytkownicy
systemu w danej organizacji
‘PROGRAMOWE’, „funkcjonalne”
• Cel:
pokazanie wymagań względem
systemu
• Granica:
Wewnątrz systemu tylko
funkcjonalność oprogramowania
(ewent. obsługiwanych urządzeń)
Rezerwacja
Z a m e ld o w a n ie
Recepcjonistka
Rejest racja zameldowania
<<include>>
G ość
W y m e ld o w a n ie
Rejestracja wymeldowania
R e c e p c jo n is ta
Płacenie
<<include>>
Sprzątaczka
Pobieranie nr pokoju do
sprz ątniecia
Zaznaczenie do sprzątnięcia
S p rz ą tn ię c ie
p o k o ju
Rejestracja s przątnięcia
slajd 7
P o k o jo w a
Przykład: Hotel Opis problemu
Hotel Hilton przyjmuje gości. Recepcjonista rejestruje
i wymeldowuje gości oraz pobiera opłatę.
W hotelu jest wiele pokoi; sprzątają je pokojowe.
Pokój może być wynajęty bezpośrednio przy przyjeździe gościa,
jeżeli istnieją wolne pokoje.
Gość płaci recepcjoniście przed wymeldowaniem.
Pokój może być posprzątany dopiero po zwolnieniu. Pokój musi
być sprzątnięty przed wynajęciem kolejnemu gościowi.
slajd 8
Diagram przypadków użycia
(biznesowy)
Zameldowanie
Gość
Wymeldowanie
Recepcjonista
Sprzątnięcie
pokoju
Pokojowa
slajd 9
Opis tekstowy przypadków użycia
• Przypadek użycia: Zameldowanie
OPIS TEKSTOWY
Sposób postępowania podczas zameldowania gościa do pokoju
PROCEDURA
S1: Gość wchodzi do hotelu.
S2: System sprawdza, czy Gość zarezerwował pokój.
S3: Jeśli TAK, wtedy przejdź do S4. Jeśli NIE, system sprawdza, czy są
wolne pokoje.
Jeśli TAK, pokój jest rezerwowany dla Gościa; przejdź do S4.
Jeśli NIE, przypadek jest kończony z komunikatem: BRAK MIEJSC.
S4: Pokój jest przydzielony Gościowi. Do Recepcjonisty jest wysyłany
komunikat PODAJ KLUCZ I KARTĘ. Gość otrzymuje klucz i kartę gościa.
slajd 10
Opis tekstowy przypadków użycia
• Przypadek użycia: Wymeldowanie
S1: Gość przybywa do recepcji z zamiarem opuszczenia hotelu.
S2: System oblicza rachunek. Gość płaci.
S3: Recepcjonista wysyła komunikat do Pokojowej, aby sprzątnęła zwalniany pokój.
S4: Do Recepcjonisty system wysyła komunikat ODBIERZ KLUCZ. Gość zwraca klucz
i kartę gościa.
• Przypadek użycia: Sprzątnięcie pokoju
S1: Pokojowa otrzymuje komunikat od Recepcjonisty o konieczności sprzątnięcia
podanego pokoju.
S2: Pokojowa sprząta pokój.
S3: Pokojowa wysyła komunikat do Recepcjonsty o sprzątnięciu pokoju.
slajd 11
Związki między przypadkami użycia
• Zawiera (include) - w starszych wersjach używa (uses)
– związek „A include B” oznacza, że w czasie wykonywania przypadku
użycia A jest wykonywana także funkcjonalność zdefiniowana przez B
• Rozszerza (extend)
– „przypadek użycia C rozszerza przypadek użycia D”, gdy opcjonalnie
(w określonych warunkach) do D zostaje włączone wykoanie
funkcjonalności C , np. C uzwględnia nową sytuację wyjątkową nie
obsługiwaną przez D.
Rejestracja
samochodu
«include»
Przegląd
samochodu
• Uogólnienie
slajd 12
«extend»
Mycie
samochodu
(Aktor-Aktor) (Przypadek użycia-Przypadek użycia)
Opis warunków na związku ze stereotypem <<extend>>
Punkt rozszerzeń (ang. extensionPoint) – miejsce w którym może nastąpić
Rozszerzenie wyspecyfikowane przez związek <<extend>>
slajd 13
Krotności
cji
a
k
i
f
y
pec
s
ć
ś
wo
Możli otności na
kr
aniu
z
ą
i
w
po
iem
k
d
a
p
przy
z
a
r
a
akto
użyci
slajd 14
Hotel – model funkcjonalny
Rezerwacja
Recepcjonistka
Rejest racja zameldowania
<<include>>
Rejestracja wymeldowania
Płacenie
<<include>>
Sprzątaczka
Pobieranie nr pokoju do
sprz ątniecia
Zaznaczenie do sprzątnięcia
Rejestracja s przątnięcia
slajd 15
Opis przypadku użycia
• Opis nieformalny
• Opis ustrukturalizowany
• Interakcje pomiędzy aktorami a systemem lub
pomiędzy obiektami w systemie na diagramach
opisujących dynamikę systemu
Cechy opisu:
• Powinien opisywać użyteczną funkcjonalność systemu.
• Powinien określać, jak i kiedy przypadek się zaczyna i kończy.
• Powinien zawierać opis interakcji przypadku użycia z aktorami
(przepływ zdarzeń, uczestniczące obiekty).
• Powinien składać się z przebiegu podstawowego oraz
przebiegów alternatywnych (wyjątkowych).
• Powinien uwzględniać związki pomiędzy przypadkami użycia.
slajd 16
Ustrukturalizowany opis przypadku
użycia
Wzorzec
opisu
slajd 17
Nazwa przypadku
Nazwy obiektów
Aktorzy
Streszczenie
Nazwa przypadku użycia
Nazwy obiektów, których dotyczy przypadek użycia
Obiekty inicjujące/biorące udział w przypadku
Skrótowy opis najważniejszych zachowań modelowanych przez
przypadek użycia
Zdarzenie inicjujące Zdarzenie rozpoczynające sekwencję interakcji
Struktura
Opis struktury przypadku użycia
Warunki początkowe Warunki umożliwiające wystąpienie danego przypadku użycia
Pełny opis
Opis interakcji pomiędzy obiektami, z wyszczególnieniem miejsc,
w których mogą wystąpić sytuacje wyjątkowe
Sytuacje wyjątkowe Opis nietypowych sytuacji (przebiegów) mogących wystąpić w
ramach przypadku użycia
Warunki końcowe
Stan, w jakim przypadek użycia pozostawia uczestniczące w nim
obiekty
Komentarz
Dodatkowe informacje nie związane z funkcjonalnością danego
przypadku użycia, przydatne w dalszych etapach modelowania
Ustrukturalizowany opis przypadku
użycia
Przykład
opisu
Nazwa przypadku
Wymeldowanie
Nazwa obiektu
System hotelowy
Aktorzy
Gość, Recepcjonista
Streszczenie
Procedura realizowana przy opuszczaniu hotelu przez gościa
Zdarzenie inicjujące Zgłoszenie wyjazdu przez Gościa
Struktura
Brak
Warunki początkowe Brak
Pełny opis
Gość zgłasza wyjazd, płaci i zwraca klucze od pokoju (wyjątek: zgubione
klucze). Recepcjonista sprawdza zapłacenie rachunku (wyjątek: nie
zapłacono) i wydaje Pokojowej polecenie sprzątnięcia pokoju.
Sytuacje wyjątkowe Zgubiono klucze: żądanie zapłacenia przez Gościa kosztu kluczy.
Nie zapłacono: żądanie zapłacenia rachunku przez Gościa.
slajd 18
Warunki końcowe
Pobyt opłacony, klucz zwrócony, zainicjowane sprzątanie pokoju.
Komentarz
Sprzątanie pokoju jest osobnym przypadkiem użycia.
Obsługa sytuacji Zgubiono klucze oraz obsługa płacenia mogą być
modelowane osobnymi przypadkami użycia.
Use Case Model in Context
Functional
requirements
specification
User
interface
design
slajd 19
Use case
model
System
design
Configuration
of the system
Test
design
Przypadki użycia w cyklu wytwarzania
oprogramowania
• Specyfikacja wymagań funkcjonalnych na system
• Weryfikacja poprawności i kompletności specyfikacji wymagań
• Wspomaganie walidacji wymagań
• Punkt wyjścia do opracowania testów (w tym akceptacyjnych)
systemu
• Identyfikacja składowych (obiektów) systemu
• Podstawa do opracowania diagramów interakcji (scenariuszy)
• Możliwość śledzenia, jak wymagania przeradzają się w klasy
obiektów i operacje systemu
• Podstawa do oceny rezultatów testów
slajd 20
Zalety modelowania
przypadkami użycia
• Określenie granic systemu i aktorów zewnętrznych
• Funkcjonalność systemu wyrażona w terminach istotnych dla aktorów
zewnętrznych
• Określenie logiki realizacji funkcjonalności w systemie
• Zrozumiałość i komunikatywność
• Przydatność w różnych fazach cyklu wytwarzania oprogramowania
• Przydatność dla celów prezentacji i dokumentacji
slajd 21
Biblioteka – model biznesowy
Wypożyczenie książki
Bibliotekarz
Czyt elnik
Zwrot książki
Korzystanie z książki w czytelni
slajd 22
Biblioteka – poglądowy model
programowy
Przeglądanie katalogu
Zamawianie książki
W ydawanie książek
Czytelnik
Zwrot ksi ążek
Sprawdzanie konta
<<extend>>
odnotownie opłaty za
przetrzymywanie
Bi bliot ekarz
W ysyłanie upomnień
Dodawanie/usuwanie ksi ążek
Zarządzanie kontami czytelników
slajd 23