Model przypadków użycia - pjwstk

MAS – dr. Inż. Mariusz Trzaska
Wykład 2
Model przypadków użycia

Zagadnienia
Prezentowanie diagramów
Stereotypy; komentarze
Klasyfikatory; wystąpienia klasyfikatorów
Związki pomiędzy elementami modelowania
Model przypadków użycia:
• Notacja
• Analiza aktorów
• Analiza przypadków użycia
• Relacje między przypadkami użycia
• Związek uogólnienia między aktorami
• Określanie aktorów
• Określanie przypadków użycia
• Dokumentowanie przypadków użycia
• Diagram interakcji dla przypadku użycia
• Podsumowanie Wykorzystano materiały z wykładu PRI autorstwa
dr inż. Ewy Stemposz oraz prof. Kazimierza Subiety
Modelowanie Systemów Informacyjnych (MSI), wykład 2
2

Prezentowanie diagramów
Diagramy mogą być prezentowane w formie:
- nieobramowanej
- obramowanej, gdzie diagram jest otoczony prostokątną ramą
zawierającą nagłówek
nagłówek-diagramu=(rodzaj) nazwa-diagramu (parametry)
nagłówek
rodzaj – wyróżnik diagramu
nazwa – odzwierciedlająca merytoryczną zawartość
diagramu
parametry – parametry kluczowe dla danego
diagramu
Nazwa jest obligatoryjnym elementem składowym nagłówka;
rodzaj i parametry są elementami nieobligatoryjnymi.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
3

Stereotypy; komentarze
Stereotypy: mechanizm rozszerzalności UML. Stereotypy są wykorzystywane
do meta-klasyfikacji elementów modelu.
Notacja: «nazwa stereotypu» lub ikona
Przykłady stereotypów:
P1
«include»
P2
P3
«extend»
P4
Komentarze: mechanizm rozszerzalności UML. Komentarze są
wykorzystywane do wprowadzania do diagramu adnotacji przypisanych do
fragmentu modelu.
tekst adnotacji
Modelowanie Systemów Informacyjnych (MSI), wykład 2
4

Klasyfikatory; wystąpienia klasyfikatorów
Klasyfikator: kategoria modelowania UML, stanowiąca uogólnienie grupy bytów o
podobnych własnościach; pojęcie klasyfikatora odnosi się do każdego rodzaju
diagramów UML.
Notacja: zależna od rodzaju diagramów
Wystąpienie klasyfikatora (instacja klasyfikatora): odpowiada konkretnemu
bytowi z grupy bytów charakteryzowanych przez dany klasyfikator
Notacja: zazwyczaj zgodna z notacją klasyfikatora; różnice występują głównie
w nazwach wystąpień: nazwa_własna_danego_bytu : nazwa_klasyfikatora
Osoba
nazwisko : string
wiek : integer
O-Nowak : Osoba
nazwisko = ” Nowak”
wiek = 35
klasyfikator
Modelowanie Systemów Informacyjnych (MSI), wykład 2
wystąpienie klasyfikatora
5

Modele wg Jacobsona
Model przypadków użycia: definiuje zarówno zewnętrze systemu (aktorzy ≡
systemy zewnętrzne ≡ kontekst systemu), jak i jego wnętrze (przypadki użycia);
służy określeniu zachowań systemu w odpowiedzi na akcje pochodzące z
otoczenia systemu.
Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego
(dziedziny problemowej ≡ dziedziny przedmiotowej) w obiekty istniejące w
systemie.
Obiektowy model analityczny: podzbiór modelu dziedziny (dotyczy
konkretnego zastosowania).
Model projektowy (logiczny): opisuje założenia przyszłej implementacji.
Model implementacyjny (fizyczny): reprezentuje implementację systemu.
Model testowania: określa plan testów, specyfikuje procedury, dane testowe,
raporty.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
6

Model analityczny
Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu.
Przyczyny:
Ujęcie w modelu pewnych elementów dziedziny problemu nie będących
częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w
modelu systemów zewnętrznych, z którymi system ma współpracować.
Na etapie modelowania może nie być jasne, które elementy modelu będą
realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie.
Dostępne środki mogą nie pozwolić na
realizację systemu w całości.
Celem budowy modelu analitycznego może
być wykrycie tych fragmentów dziedziny
problemu, których wspomaganie za
pomocą innego oprogramowania będzie
szczególnie przydatne.
Dziedzina problemu
Model analityczny
Zakres
odpowiedzialności
systemu
Modelowanie Systemów Informacyjnych (MSI), wykład 2
7

Model wymagań
Składowe:
• Model przypadków użycia
• Obiektowy model analityczny
Model przypadków użycia został oparty o dwa podstawowe pojęcia:
Aktor
Przypadek użycia
Reprezentuje rolę, którą może grać w systemie
jakiś jego użytkownik, np. kierownik, urzędnik,
klient.
Reprezentuje sekwencję operacji (realizowanych
przez system), niezbędnych do wykonania zadania
zleconego przez aktora, np. potwierdzenie pisma,
złożenie zamówienia, itp.
Aktorem jest dowolny byt z otoczenia systemu, który uczestniczy w interakcji z
systemem. Każdy potencjalny aktor może wchodzić w interakcję z systemem na
pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę
przypadku użycia i reprezentuje przepływ operacji w systemie związany z
obsługą zadania zleconego przez aktora w procesie interakcji.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
8

Notacja
Wypłata
pieniędzy
Klient
Weryfikacja
klienta
«include»
ud Obsługa klienta
Przypadek użycia: Powinien mieć unikatową nazwę,
opisującą przypadek użycia z punktu widzenia jego
zasadniczych celów. Czy lepiej jest stosować nazwę
opisującą czynność (“wypłata pieniędzy”/„wypłacanie
pieniędzy”) czy polecenie (“wypłać pieniądze”) − zdania są
podzielone.
Aktor: Powinien mieć unikatową nazwę.
Interakcja: Ilustruje związek asocjacji zachodzący
pomiędzy przypadkiem użycia (systemem) a aktorem.
Blok ponownego użycia: Wewnętrzny fragment systemu,
używany przez kilka przypadków użycia; blok ponownego
użycia nie jest elementem UML.
Relacja typu «include» lub «extend»: Pokazuje związek
zależności zachodzący pomiędzy dwoma przypadkami
użycia lub przypadkiem użycia a blokiem ponownego
użycia.
Nazwa diagramu wraz z nagłówkiem i ramą: ud (ang.
use case diagram) – wyróżnik diagramu.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
9

Aktor − kto (co) może wystąpić w roli
aktora
Metoda przypadków użycia wymaga od analityka określenia wszystkich
aktorów związanych z planowanym wykorzystywaniem projektowanego
systemu, innymi słowy wymaga ustalenia zbioru “przyszłych
użytkowników systemu”.
Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np.
biuro prawne), inny system komputerowy lub urządzenie. Aktor modeluje grupę
osób pełniących pewną rolę, a nie konkretną osobę. Jedna osoba może
wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno
sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu
konkretnym osobom, np. aktor “strażnik budynku”.
(1) Czy system może być aktorem sam dla siebie Aktor to przecież, zgodnie
z definicją, byt z otoczenia systemu.
(2) Aktor jest pierwotną przyczyną napędzającą przypadki użycia. Jest
sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jest też
odbiorcą danych wyprodukowanych przez przypadek użycia. Sprawca
zdarzeń Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji
systemu jest aktorem
(3) Aktor pasywny a interakcja z systemem
Modelowanie Systemów Informacyjnych (MSI), wykład 2
10

Analiza aktorów
Wyjaśnienie różnicy pomiędzy pojęciem „konkretny
użytkownik” a pojęciem „aktor”:
Konkretny
użytkownik
Może grać rolę
Aktor
zleca
Przypadek użycia
Jan Kowalski
Administrator systemu
Przeładowanie systemu
Adam Malina
Konkretny
gość
Konkretny klient
Pracownik
Osoba informowana
Klient
Wejście z kartą i kodem
Uzyskanie
informacji ogólnych
Wypłata z konta
Modelowanie Systemów Informacyjnych (MSI), wykład 2
11

Wykorzystanie stereotypów dla aktorów
Aktor: człowiek,
grupa ludzi,
organizacja
Klient
«actor»
Klient
Klient
Aktor: system zewnętrzny
System
ubezpieczeń
Aktor: czas
1-szy dzień
roku
Modelowanie Systemów Informacyjnych (MSI), wykład 2
12

Przykład diagramu przypadków użycia (1)
Wpłata pieniędzy
Klient
Wypłata pieniędzy
Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy – to zależy od
konkretnego systemu. W operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć
także inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element
rozbudowujący nasz model.
Wpłata pieniędzy
Klient
Wypłata pieniędzy
Modelowanie Systemów Informacyjnych (MSI), wykład 2
Kasjer
alternatywna notacja dla przypadków
użycia
13

Przykład diagramu przypadków użycia (2)
ud Automat do sprzedaży papierosów
Uzupełnienie
towaru
Klient
Zakup paczki
papierosów
Wykonanie operacji
pieniężnej
Operator
Sporządzenie
raportu
Kontroler
Modelowanie Systemów Informacyjnych (MSI), wykład 2
14

Liczność związków asocjacji
ud Automat do sprzedaży papierosów
Uzupełnienie
towaru
*
1
Klient
1
*
Zakup paczki
papierosów
Wykonanie operacji
pieniężnej
Sporządzenie
raportu
*
*
*
1
Operator
1
1
Kontroler
Modelowanie Systemów Informacyjnych (MSI), wykład 2
15

Oznaczanie kierunków interakcji
ud Automat do sprzedaży papierosów
Uzupełnienie
towaru
Klient
Zakup paczki
papierosów
Wykonanie operacji
pieniężnej
Operator
Sporządzenie
raportu
System
archiwizujący
Modelowanie Systemów Informacyjnych (MSI), wykład 2
16

Relacje między przypadkami użycia (1)
Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że
występują między nimi związki zależności typu «include» czy «extend».
W obu poniższych diagramach P1, nazywane tu przypadkiem bazowym,
zawsze występuje jako pierwsze w kolejności działania.
Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2, zwane tu
przypadkiem włączanym.
P1
«include»
P2
Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P2, zwane
tu przypadkiem rozszerzającym (inaczej: P2 czasami rozszerza P1).
Sformułowanie “czasami” oznacza, że warunek na wywołanie P2 musi być
spełniony, aby P2 zostało wywołane z P1. O ile warunek nie został
wyspecyfikowany − co jest dopuszczalne − P2 będzie wywołane zawsze.
P1
«extend»
P2
Modelowanie Systemów Informacyjnych (MSI), wykład 2
17

Relacje między przypadkami użycia (2)
Rejestracja
klienta
«include»
Przegląd
samochodu
«include»
«extend»
«include»
Sprzedaż
samochodu
Naprawa
samochodu
«include» wskazuje na wspólny
fragment wielu przypadków
użycia (wyłączony “przed
nawias”); jest wykorzystywane w
przebiegach podstawowych
(przypadek włączany jest zawsze
wykonywany) − strzałka jest
skierowana w stronę przypadku
włączanego
Umycie
samochodu
«extend»
«extend»
Przyholowanie
samochodu
«extend» jest wykorzystywane w
przebiegach opcjonalnych
(przypadek rozszerzający nie
zawsze będzie wykonywany) −
strzałka jest skierowana w stronę
przypadku bazowego
Modelowanie Systemów Informacyjnych (MSI), wykład 2
18

Relacje między przypadkami użycia (3)
Naprawa
samochodu
extension points:
Samochód poza warsztatem
Samochód wymaga przeglądu
«extend»
extension point:
Samochód poza
warsztatem
«exten
d»
extension point:
Samochód wymaga
przeglądu
Punkty rozszerzające
(extension points)
Umożliwiają podanie warunków
wymaganych do użycia
przypadków rozszerzających
(„opcjonalnych”).
Przegląd
samochodu
extension points:
Samochód jest brudny
Przyholowanie
samochodu
Umycie
samochodu
«extend»
extension point:
Samochód jest
brudny
Modelowanie Systemów Informacyjnych (MSI), wykład 2
19

Relacje między przypadkami użycia (3)
Uwaga: Zabronione jest łączenie relacją «include» (czy «extend») przypadków
użycia występujących w różnych przebiegach systemu, jak np. na poniższym
diagramie.
Złożenie zamówienia
Klient
«extend»
Dostawca
Realizacja zamówienia
Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
20

Związek uogólnienia między aktorami (1)
Osoba
Pracownik
Gość
Księgowa
Pracownik
administracji
Np. Pracownik administracji dziedziczy dostęp do przypadków użycia
wyspecyfikowanych dla każdego pracownika, oraz ma dostęp do przypadków
związanych z jego własnym, specyficznym sposobem wykorzystywania systemu.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
21

Związek uogólnienia między aktorami (2)
ud Automat do operacji bankowych
Podsystem
zarządzania bazą
danych banku
Obsługa
konta klienta
«include»
Informowanie o
stanie konta klienta
«include»
Weryfikacja karty
i kodu klienta
Klient
Administrator
systemu
Inicjalizacja
karty klienta
«include»
Modelowanie Systemów Informacyjnych (MSI), wykład 2
22

Związek uogólnienia między aktorami (3)
ud Automat do operacji bankowych
Podsystem
zarządzania bazą
danych banku
Obsługa
konta klienta
«include»
Informowanie o
stanie konta klienta
«include»
Weryfikacja karty
i kodu klienta
Klient
Administrator
systemu
Inicjalizacja
karty klienta
«include»
Modelowanie Systemów Informacyjnych (MSI), wykład 2
23

Rozbudowa modelu przypadków użycia
Wpłać
pieniądze
Wpłać
pieniądze
Kasjer
Klient
banku
Wypłać
pieniądze
Sprawdź
stan konta
Kasjer
Klient
banku
Wypłać
pieniądze
«include»
Sprawdź
stan konta
«extend»
«include»
Uaktualnianie
stanu konta
Weź
pożyczkę
Zarząd
banku
Weź
pożyczkę
Zarząd
banku
Model przypadków użycia można rozbudowywać poprzez dodawanie nowych
aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy
przypadkami.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
24

Diagram kontekstowy
Podsystem
zarządzania bazą
danych banku
Klient
«system»
Automat do
operacji
bankowych
Administrator
systemu
Modelowanie Systemów Informacyjnych (MSI), wykład 2
25

Przepływ zdarzeń (1)
Jednym z najważniejszych elementów w opisie każdego przypadku użycia
– na etapie formułowania wymagań – jest specyfikacja przepływu zdarzeń
między aktorem a systemem. Specyfikację przepływu zdarzeń należy
formułować w języku naturalnym: prostą, spójną prozą i w oparciu o terminy
zawarte w słowniku pojęć z dziedziny problemowej.
Na przykład, przepływ zdarzeń między aktorem a systemem dla
bankomatu, dla przypadku użycia “Wypłać pieniądze”, mógłby być
opisany, jak poniżej:
1. Przypadek użycia rozpoczyna się, gdy klient wkłada kartę do
bankomatu.
System czyta informacje na karcie i bada ich poprawność.
2. System pyta o PIN. Klient wprowadza PIN. System sprawdza
poprawność.
3. System pyta o rodzaj operacji do wykonania. Klient wybiera: “Wypłać
pieniądze”.
4. System pyta o wielkość kwoty. Klient wprowadza kwotę.
5. System komunikuje się z bankiem, żeby sprawdzić poprawność ID
konta, PIN i dostępność kwoty.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
26

Przepływ zdarzeń (2)
6. System pyta klienta czy potrzebuje potwierdzenie.
7. System komunikuje klientowi prośbę o zabranie karty. Klient zabiera
kartę.
Komunikat stanowi tu pewien mechanizm bezpieczeństwa chroniący
klienta
przed nie zabraniem karty.
8. System wydaje pieniądze.
9. System drukuje potwierdzenie (o ile klient sobie życzył) i to kończy
przypadek użycia.
Możliwe są różne, alternatywne przepływy dla tego przypadku użycia:
• Dane od aktora: np. aktor może unieważnić transakcję w dowolnym momencie
lub może nie chcieć potwierdzenia.
• Stan systemu: np. bankomat może nie zawierać pieniędzy, może brakować
papieru, może nastąpić blokada urządzenia wydającego pieniądze czy też
blokada urządzenia drukującego potwierdzenie.
• Time-out lub błędy: np. jeśli klient nie odpowie w określonym czasie, system
może unieważnić transakcję.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
27

Scenariusze
Każdy alternatywny przepływ nie oznacza oddzielnego przypadku użycia
raczej grupujemy wszystkie powiązane przepływy w jeden przypadek użycia.
Taką grupę przepływów czasami nazywa się klasą przypadków użycia.
Wystąpieniem klasy przypadków użycia jest wtedy jeden z pojedynczych,
alternatywnych przepływów.
Wystąpienie klasy przypadków użycia jest także nazywane scenariuszem.
Scenariusze są używane do “ekstrahowania” z przypadku użycia
unikatowej sekwencji akcji, inaczej: “wątków” w przypadku użycia.
Na wczesnych etapach rozwoju systemu łatwiej jest rozpocząć prace od
pewnego konkretnego scenariusza, a następnie dokładać przepływy
alternatywne − w ten sposób tworzy się klasę przypadków użycia.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
28

Kolejne kroki w konstrukcji modelu
Konstrukcja modelu przypadków użycia opiera się na kilku krokach i wymaga ścisłej
współpracy z przyszłym użytkownikiem, co implikuje zasadę: “nie opisuj przypadków
użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika”.
Jednocześnie powinien być budowany obiektowy model analityczny (schemat pojęciowy
1
2
Krok:
Sporządzenie słownika pojęć
Określenie aktorów
Udokumentowany w:
Słownik pojęć
3
4
Określenie przypadków
użycia
Tworzenie opisu każdego
przypadku
użycia plus:
• podział na nazwane części
• znalezienie wspólnych części
Modelowanie Systemów Informacyjnych (MSI), wykład 2
Dokument opisu aktorów
Diagram przypadków użycia +
dokument z opisem przypadków
użycia
29

Krok 1: sporządzenie słownika pojęć
• Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć.
• Słownik dotyczy dziedziny problemowej.
• Tworzenie go polega na wyłowieniu wszystkich pojęć z wymagań
użytkownika.
• Pojęcia mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji,
zdarzeń, itp.
• Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny i
jednoznaczny.
• Posługiwanie się pojęciami ze słownika powinno być regułą przy opisie
każdego kolejnego problemu, sytuacji czy modelu.
Na co należy zwracać uwagę przy kwalifikowaniu pojęć do
słownika:
• na rzeczowniki − mogą oznaczać aktorów lub byty z dziedziny
problemowej, na frazy opisujące funkcje, akcje, zachowanie się −
mogą stanowić podstawę do wyróżniania przypadków użycia.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
30

Krok 2: określanie aktorów
Przy określaniu aktorów istotne są odpowiedzi na następujące
pytania:
• Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu (np.
osoba
wysyłająca korespondencję)
• Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał
swoje
funkcje (np. administrator systemu)
• Z jakich elementów zewnętrznych (innych systemów, urządzeń) musi
Ustalanie korzystać potencjalnych aktorów musi być powiązane z ustalaniem granic
systemu, system, tj. odrzucaniem aby realizować tych obszarów swoje funkcje. dziedziny problemowej, którymi system
nie będzie się zajmował (ustalenie zakresu odpowiedzialności systemu).
Po wyszukaniu aktorów, należy ustalić:
• nazwę dla każdego aktora/roli,
• zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy
zakresami (np. sekretarka pracownik administracji pracownik dowolna
osoba). Niekiedy warto ustalić hierarchię dziedziczenia dostępu do funkcji
systemu dla aktorów.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
31

Krok 3: określanie przypadków użycia (1)
Nazwy dla przypadków użycia powinny być krótkie, ale jednoznacznie
określające charakter zadania zlecanego systemowi przez aktora. Ponadto,
nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie
systemu, czyli np. “wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.
funkcja systemu ≡ zachowanie systemu ≡ przypadek użycia
Dla każdego aktora, znajdź zadania: (1) w których system może go wesprzeć w
działalności związanej z dziedziną przedmiotową, (2) niezbędne dla wspomagania
działania systemu jako takiego (np. zakładanie kont użytkowników).
Staraj się powiązać w jeden przypadek użycia zespół zadań realizujących
podobne cele. Unikaj rozbicia jednego przypadku na zbyt wiele pod-przypadków.
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.
Przeanalizuj zarówno wyspecyfikowane przypadki użycia (niektóre z nich mogą
być „mutacjami” innych przypadków użycia), jak i powiązania aktorów z przypadkami
użycia. Ustal, co jest zbędne, a co może być uogólnione.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
32

Określanie przypadków użycia (2)
W pierwszym podejściu skup się na tzw. „przypadkach krytycznych”, czyli takich,
które stanowią istotę systemu (są normalnym, standardowym użyciem) lub są
ważne z powodu istniejących w projekcie ryzyk (np. ryzyk technologicznych). Pomiń
czynności wyjątkowe, uzupełniające lub opcjonalne; pomiń przypadki użycia typu
Create Read Update Delete.
Określ wzajemne powiązania przypadków, wyspecyfikuj rodzaj zależności:
sekwencja («include») czy alternatywa («extend»).
Dodaj zachowania wyjątkowe, uzupełniające, opcjonalne i CRUD. Ustal związki
“przypadków krytycznych” z tego rodzaju zachowaniami.
Tworząc podział każdego przypadku użycia na nazwane części (bloki), staraj się,
aby nie były one ani zbyt ogólne ani zbyt szczegółowe. Zbyt szczegółowe bloki
utrudniają analizę, a zbyt ogólne zmniejszają możliwość wykrycia fragmentów
oprogramowania posiadających potencjał ponownego użycia. Całość diagramu nie
może być ani zbyt duża ani zbyt złożona.
Przeanalizuj przypadki użycia pod kątem wyizolowania bloków ponownego
użycia. Przeanalizuj podobieństwo nazw przypadków użycia, Wydzielenie bloku
ponownego użycia może być powiązane z określeniem bardziej ogólnych zadań lub
dodaniu nowych elementów do już istniejącego zadania.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
33

Krok 4: dokumentowanie przypadków użycia
Dokumentacja przypadków użycia powinna zawierać:
1. Diagramy przypadków użycia: aktorzy, przypadki użycia i relacje zachodzące
między
przypadkami.
2. Krótki, ogólny opis każdego przypadku użycia:
• jak i kiedy przypadek użycia zaczyna się i kończy,
• opis interakcji przypadku użycia z aktorami, włączając w to kiedy
interakcja ma
miejsce i co jest przesyłane,
• kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w
systemie oraz jak i kiedy zapamiętuje dane w systemie,
• wyjątki występujące przy obsłudze przypadku,
• specjalne wymagania, np. czas odpowiedzi, wydajność,
3. Opis szczegółowy każdego przypadku użycia:
• scenariusz(e)
• specyfikację uczestniczących obiektów,
• diagram(y) interakcji.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
34

Dokumentacja przypadku Wypożycz kasetę
Nazwa
Nr id 7
Autor
Priorytet
Typ
Aktorzy
Opis
Warunek początkowy
Warunek końcowy
(1)
Wypożycz kasetę
Jan Kowalski - analityk
Wysoki
Ogólny
Pracownik wypożyczalni
Przypadek dotyczy rejestracji wypożyczenia kaset; kasety
przeznaczone dla dorosłych można wypożyczać od 18-tego roku
życia; jednocześnie można mieć wypożyczonych co najwyżej 5
kaset; nie wolno wypożyczać osobie, która aktualnie znajduje
się w okresie karencji
Osoba wypożyczająca powinna być zarejestrowana jako klient
wypożyczalni
O ile warunki wypożyczenia zostały zrealizowane, to powinny
zostać zarejestrowane następujące informacje o wypożyczeniu
kasety : kto wypożyczył, co wypożyczył i kiedy wypożyczył

Dokumentacja przypadku Wypożycz kasetę
(2)
Główny przepływ zdarzeń
Alternatywne przepływy
zdarzeń
1. Pracownik wypożyczalni uruchamia przypadek Wypożycz
kasetę.
2. System odpytuje o nazwisko i imię osoby wypożycząjącej.
Pracownik wprowadza odpowiednie informacje.
3. System odpytuje o tytuł filmu. Pracownik wprowadza tytuł.
4. System rejestruje wypożyczenie kasety z filmem (kto, co,
data wypożyczenia).
2a O ile osoba wypożyczająca nie jest zarejestrowana w
systemie, system informuje o tym aktora i kończy
przypadek użycia
2b. O ile jest zarejestrowana więcej niż jedna osoba o tym
samym nazwisku i imieniu, system wyświetla okno z
listą osób. Pracownik wybiera odpowiednią osobę z listy.
3a O ile aktualnie nie ma filmu o tym tytule w zasobach
wypożyczalni, lub wszystkie kasety z filmem są
wypożyczone, system informuje o tym aktora i kończy
przypadek.
3b O ile film jest przeznaczony dla osób dorosłych a osoba
wypożyczająca nie ukończyła 18-tu lat, system informuje o
tym aktora i kończy przypadek.

Dokumentacja przypadku Wypożycz kasetę
(3)
Alternatywne przepływy
zdarzeń, cd.
Wymagania niefunkcjonalne
3c Jeśli osoba wypożyczająca ma już aktualnie co najmniej
pięć wypożyczonych kaset na koncie, system informuje
o tym aktora i kończy przypadek.
3d Jeśli osoba wypożyczająca znajduje się aktualnie w
okresie karencyjnym, system informuje o tym aktora i
kończy przypadek.
Brak
Uwagi dodatkowe
Brak

Podsumowanie
Główne zadanie modelu przypadków użycia to określenie poprawnych
wymagań funkcjonalnych na projektowany system, co jest uznawane za
jeden z podstawowych problemów w procesie budowy systemu.
Ponadto, model przypadków użycia pozwala na:
• lepsze zrozumienie możliwych sposobów wykorzystania projektowanego
systemu (przypadków użycia), lepsze zrozumienie jego funkcjonalności − co w
efekcie oznacza zwiększenie stopnia świadomości uczestników projektu co do
celów systemu,
• umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami
systemu,
• ustalenie praw dostępu do zasobów,
• zrozumienie strukturalnych własności systemu, a przez to ustalenie
składowych systemu i związanego z nimi planu budowy systemu,
• dostarczenie podstawy do sporządzenia harmonogramu prac,
• dostarczenie bazy do budowy planu testów systemu,
Przypadki użycia powinny odwzorowywać strukturę systemu
tak, jak tę strukturę widzą przyszli użytkownicy systemu.
Modelowanie Systemów Informacyjnych (MSI), wykład 2
38