Zadanie 3 Przypadki użycia

Przypadki użycia są podstawowym narzędziem specyfikacji wymagań. Wizualnie, wydają się podobne do diagramów DFD, jednakże opisują funkcjonowanie systemu w inny sposób (zazwyczaj jako czarną skrzynkę):

Przypadek użycia to specyfikacja ciągów akcji i ich wariantów, które system lub inna jednostka może wykonać poprzez interakcję z aktorem tego sytemu, który prowadzi do obserwowalnego rezultatu, zazwyczaj mającego wartość dla jednego lub kilku aktorów lub innych udziałowców systemu

Mimo wizualnego podobieństwa do procesów z diagramów DFD, przypadki użycia są czymś zupełnie innym. Może się zdarzyć, że specyfikacja DFD będzie zawierała 100 procesów, a równocześnie system będzie realizował tylko kilka przypadków użycia. Przypadki użycia definiują to, czego brakuje w DFD do pełnego zrozumienia sposobu funkcjonowania systemu – definiują scenariusz określający w jakiej kolejności są przesyłane dane i zdarzenia pomiędzy obiektami na zewnątrz systemu (użytkownikami, interfejsami) a systemem.

1. Przeczytaj krótki tekst o przypadkach użycia.
2. Narysuj diagram przypadków użycia dla wybranego wcześniej projektu.
3. Opcjonalnie: w przypadku mniejszych projektów zaproponuj rozszerzenie funkcjonalności. Np.: dodaj administrację użytkownikami, generowanie i przeglądanie raportów sprzedaży lub podobne funkcje tak, aby system miał co najmniej kilka (5-10) przypadków użycia.
4. Dla trzech przypadków użycia napisz dokładne scenariusze posługując się szablonem opisu przypadku użycia oraz wzorcami zamieszczonymi we fragmencie książki Alistaira Cocburna Writting Effective Use Cases na str. 23.

• Biznesowe przypadki użycia definiują funkcjonowanie organizacji i świadczone przez nią usługi na rzecz zewnętrznych aktorów. Zawierają często czynności manualne. Ich specyfikacja nie jest celem zadania.
• Systemowe przypadki użycia opisują interakcje aktorów z systemem informatycznym. Nie ma tu czynności manualnych. Dodatkowo, bardzo często aktor biznesowy nie jest aktorem systemowym, bo nie ma dostępu do funkcji systemu.

Więcej - na początku tekstu Antywzorce w stosowaniu UML

Pomiędzy przypadkami użycia mogą zachodzić relacje oznaczane «include» i «extend»

• Include – wyobraźmy sobie, że piszemy przypadki użycia dla systemu aukcji internetowych. Dla części przypadków użycia (licytacja, komentarze, przesyłanie poczty) konieczne jest logowanie. Zamiast powtórzyć za każdym razem w scenariuszu kilka kroków logowania, możemy wyodrębnić przypadek użycia “Logowanie” i powiedzieć, że wołamy go w punkcie x lub y.

Alternatywnie, możemy podać prewarunek: użytkownik musi być zalogowany. Nie warto tworzyć przypadku użycia, który miałby być włączony tylko jeden raz!

• Extend – jeżeli mamy dwa podobne przypadki, różniące się np.: w kilku punktach scenariusza możemy zdefiniować przypadek rozszerzający:

Np. dla przykładu Budzik – Ustawianie daty i czasu zamiast: 3 ustawianie daty za pomocą klawiszy góra dół – wprowadzamy datę za pomocą klawiszy numerycznych

Dalsze przykłady można znaleźć w literaturze.

Relacje to dobry temat na egzamin, ale nie należy ich nadużywać. Proszę zajrzeć do Antywzorców

Przypadki użycia definiują wymagania stawiane systemowi, są powszechnie akceptowane jako metoda komunikacji z klientem i są źródłem testów i podstawą do akceptacji gotowego systemu.

Naturalne jest, że klient zatwierdzając przypadek użycia jest także zainteresowany przesyłanymi danymi i ich kompletnością i spójnością.

Zazwyczaj definiowanie przypadków użycia następuje PO etapie analizy dziedziny (określenie klas i ich powiązań). W naszym przypadku tę rolę ma pełnić ERD oraz specyfikacje przepływów danych.

Dlatego należy unikać ogólników:

1. Pracownik wprowadza dane
2. System po weryfikacji zapisuje dane w bazie

Lepiej:

Scenariusz główny

1. Pracownik wprowadza dane klienta (imię, nazwisko, datę urodzenia, numer pesel, adres)
2. System weryfikuje dane. 
3. System dodaje klienta do bazy klientów

Scenariusz alternatywny

2.a. Klient o danym numerze pesel jest już w bazie

2.a.1 System wyświetla komunikat, że użytkownik o danym numerze pesel istnieje i pyta czy zmodyfikować dane
2.a.2 Pracownik potwierdza
2.a.3. System zapisuje zmodyfikowane dane w bazie klientów; przypadek użycia kończy się

2.a.2.a Pracownik wybiera opcję ponownej edycji danych
2.a.2.a.1 System ponownie wyświetla formatkę wypełnioną danymi. Pole pesel jest puste. 
2.a.2.a.2 Następuje powrót do punktu (1) scenariusza głównego 

2.b. Brak zgodności numeru pesel i daty urodzenia
....
itd.

Definiując przypadki użycia należy wystrzegać się:

• zbyt dużej ich liczby (np. system realizowany przez kilkadziesiąt osobomiesięcy może mieć około 100 przypadków użycia, więc osiągnięcie podobnej liczby dla małego systemu jest co najmniej niepokojące)
• definiowanie ich przez dekompozycję. Możemy mieć grupę przypadków użycia Administracja użytkownikami, ale nie jest to przypadek użycia, który włącza (czytaj: dekomponuje się na) dodaj/usuń/modyfikuj
• nadużywania relacji. Relacje ładnie wyglądają na diagramie, ale czasem zaciemniają scenariusze. Nie należy definiować przypadku użycia tylko po to, aby go włączyć jeden raz.
• przenoszenia interfejsu graficzny, zwłaszcza opcji menu na przypadki użycia
• definiowania przypadków użycia praktycznie bez scenariusza (użytkownik wybiera zapisz, system zapisuje plik) Oznacza to, że albo przypadek jest źle dobrany do stopnia szczegółowości specyfikacji, albo nasza wyobraźnia jest zbyt mała (nie uwzględniliśmy scenariusza, gdy plik istnieje, gdy nie da się zapisać, gdy plik o tej samej nazwie jest otwarty, itd.)

1. Cockburn Alistair Jak pisać efektywne przypadki użycia
2. Schneider Geri, Winters Jason P. Stosowanie przypadków użycia
3. Fragment książki Alistaira Cocburna Writting Effective Use Cases
4. Wykład - przypadki użycia
5. Antywzorce w stosowaniu UML Koniecznie należy przeczytać
6. Booch G.,Rumbaugh J.,Jacobson I.:The Unified Modeling Language User Guide.Addison-Wesley, 1998, tłum. Na język polski: UML przewodnik użytkownika. WNT 2001
7. Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski: UML 2.0 w modelowaniu systemów informatycznych, Helion
8. UML Reference Manual (1.0)
9. Specyfikacja OMG UML