Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

Transkrypt

1 Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

2 Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!! określenie wymagań!!! Podejście przypadków użycia ma przede wszystkim na względzie ten problem.

3 Definicje Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy. Przypadek użycia specyfikuje zachowanie systemu lub jego części. Jest to opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku Ich głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach opartych na UML przypadkom użycia przypisuje się szczególne znaczenie jako środka napędzającego cały proces rozwoju systemu.

4 Przypadki użycia w analizie Eksperci Potrzeby Pomysły Koncepcja zastosowania Doświadczenie w dziedzinie przedmiotowej Model dziedziny Kompletny model analizy Technologie Przypadki użycia Model zastosowania Użytkownicy mocny wpływ słaby wpływ

5 Przypadki użycia w analizie c.d. Cele : głębsze zrozumienie użycia systemu (z punktu widzenia użytkownika) zwiekszenie stopnia świadomości analityków i projektantów umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu weryfikacja poprawności i kompletności projektu ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu dostarczenie podstawy do sporządzenia planu testów systemu

6 Projektowanie mieszkania Co bierzemy pod uwagę? poruszanie się po mieszkaniu miejsce na urządzenia, np. w kuchni szybka droga z garażu do kuchni odpowiednia wielkość pokoi... analiza oparta na przypadkach użycia W ten sposób kształtuje się architekturę mieszkania Konsultacja z architektem (ekspertem)

7 Zalety zastosowania Nie narzucają sposobu implementacji pozwalają zapomnieć o strukturze i architekturze systemu i jego detalach technicznych na etapie analizy Użytkownicy i eksperci mogą rozmawiać z projektantami i programistami bez konieczności analizowania nieistotnych szczegółów Intuicyjna reprezentacja funkcjonalna systemu, nie wprowadza komputerowego żargonu Posiadają notację graficzną Język zunifikowany, znany na całym świecie

8 Aktor Używa systemu na wiele sposobów (przypadków użycia) Jest sprawcą zdarzeń powodujących uruchomienie przypadków użycia Odbiera informacje wyprodukowane przez system Jest modelem (obiektem), nie konkretną osobą reprezentuje rolę, jaką może grać konkretny użytkownik Można tworzyć aktorów abstrakcyjnych (nadklasy)

9 Notacje 1. Graficzna 2. Tekstowa

10 Notacja graficzna - pojęcia Przypadek użycia To unikalna nazwa, która opisuje przypadek z punktu widzenia głównego aktora Aktor Reprezentuje zbiór ról odgrywanych przez użytkowików przypadku użycia. Zwykle jest to człowiek, maszyna, inny system Powinien mieć unikalną, jednoznaczną nazwę

11 Notacja graficzna - pojęcia c.d. Interakcje Pokazuje związek między przypadkiem użycia i aktorem (środowiskiem zewnętrznym) Blok ponownego użycia weryfikacja klienta Pokazuje pewien fragment działalności systemu, który jest używany w kilku przypadkach użycia. (Może być także oznaczony jako samodzielny przypadek użycia).

12 Notacja graficzna - pojęcia c.d. Asocjacje z blokiem ponownego użycia Pokazuje związek przypadku użycia z pewnym blokiem ponownego użycia Nazwa systemu wraz z granicami systemu System obsługi klienta Pokazuje granicę pomiędzy systemem i jego otoczeniem...system informacyjny...

13 Przykład diagramu PU (Siergiej) wpłata pieniedzy klient banku wypłata pieniedzy Woperacjach wpłaty i wypłaty pieniędzy uczestniczą takze inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujacy wpłata pieniedzy klient banku wypłata pieniedzy kasjer

14 Przykład diagramu PU 2 Automat do sprzedaży papierosów uzupełnienie towaru zakup paczki papierosów operacje pieniężne klient sporządzenie raportów operator kontroler

15 <<rozszerza>> i <<używa>> Relacje pomiędzy przypadkami użycia rejestracja klienta używa używa używa sprzedaż samochodu używa: wskazuje na wspólny fragment wielu przypadków użycia, wyłączony przed nawias (w tym sensie jest abstrakcyjny, podobieństwo do dziedziczenia) przegląd samochodu rozszerza umycie samochodu rozszerza naprawa samochodu rozszerza przyholowanie samochodu rozszerza: strzałka prowadzi od przypadku użycia, który czasami (nie zawsze) rozszerza przypadki użycia.

16 Powiązania w modelu PU «uses» Modeluje sytuację kiedy przypadek (przypadki) użycia wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok ponownego użycia) na zasadzie podobnej do wywołania procedury. «extends» Modeluje sytuację kiedy rozszerzający przypadek użycia definiuje wspólne lub dobrze wyodrębnione akcje. Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w nim akcje plus niekiedy dodatkowo akcje określane przez przypadek rozszerząjący. Jest on zwykle niekompletny. Zmiany: «uses» «import», «extends» «extend»

17 Zależności czasowe między PU Właściwie nie występuje w tym modelu nacisk na uwzględnianie zależności czasowych między przypadkami użycia, tzn. nie interesuje nas wzajemna kolejność przypadków użycia (co oznacza, że mogą być konstruowane w dowolnej kolejności), ale jeśli... p1 <<używa>> p2 Przebieg podstawowy - p1 (przypadek bazowy, podstawowy) zawsze używa p2, a więc p1 musi być pierwsze w kolejności działania. p1 <<rozszerza>> p2 Przebieg opcjonalny - p1 (przypadek bazowy) jest czasami rozszerzane o p2, tutaj też p1 musi być pierwsze w kolejności działania.

18 Przykład diagramu 3 (Bartek) Automat do operacji bankowych Baza danych banku Prowadzenie konta klienta <<używa>> Klient Administrator systemu Informowanie o stanie konta klienta Inicjalizacja karty klienta <<używa>> <<używa>> Weryfikacja karty i kodu klienta

19 Notacja tekstowa Przypadek użycia może być wyspecyfikowany przez opisanie ciągu zdarzeń w formie tekstu zrozumiałego nawet dla laika. Wymagane informacje : Jak i kiedy zaczyna się i kończy Kiedy dochodzi do interakcji z aktorami Jakie obiekty są przekazywane Główny ciąg zdarzeń

20 Notacja tekstowa - przykład Weryfikacja użytkownika Główny ciąg zdarzeń : Przypadek użycia zaczyna się, gdy system pyta klienta o PIN. Klient może teraz wprowadzić hasło z klawiatury. Klient potwierdza wprowadzone dane za pomocą klawisza Wykonaj. System sprawdza poprawność PIN`u. Jeśli jest on poprawny, system informuje o tym. Na tym kończy się przypadek użycia. Nadzwyczajny ciąg zdarzeń : Klient może w każdej chwili anulować transakcję, naciskając klawisz Stop. Przypadek użycia wraca teraz do punktu początkowego. Na koncie klienta nie zachodzą żadne zmiany

21 Przykład c.d. Weryfikacja użytkownika Nadzwyczajny ciąg zdarzeń : Przed potwierdzeniem PIN`u Klient może w każdej chwili wprowadzić go jeszcze raz. Nadzwyczajny ciąg zdarzeń : Gdy klient wprowadzi błędny PIN, przypadek użycia wraca do punktu początkowego. Gdy zdarzy się to trzy razy z rzędu, system anuluje całą transakcję i przez 60 sekund nie reaguje na żadne działania klienta.

22 Rozbudowa modelu PU (Siergiej) wpłata pieniedzy wpłata pieniedzy wypłata pieniedzy kasjer wypłata pieniedzy kasjer używa klient banku sprawdź bilans klient banku sprawdź bilans weź pożyczkę zarząd banku weź pożyczkę zarząd banku

23 Charakterystyka PU W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich w postaci scenariuszy. programista edycja programu używa wykonanie programu kompilacja programu używa drukowanie pliku Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele. użytkownik

24 Opis przypadków użycia Co powinien zawierać opis przypadku użycia? Opis przypadku użycia może być dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty: 1) Jak i kiedy przypadek użycia zaczyna się i kończy? 2) Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. 3) Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie? 4) Wyjątki przy przepływie zdarzeń. 5) Jak i kiedy używane są pojęcia dziedziny problemowej?

25 Dokumentacja PU 1. Krótki opis przypadku użycia 2. Przepływ zdarzeń opisany nieformalnie 3. Asocjacje pomiędzy przypadkami użycia 4. Uczestniczące obiekty 5. Specjalne wymagania (np. czas odpowiedzi, wydajność) 6. Obrazy interfejsu użytkownika 7. Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów) 8. Diagramy interakcji dla każdego aktora

26 Metoda oparta na PU Metoda dotyczy analizy wymagań i opiera się na kilku krokach. Jednocześnie jest budowany obiektowy model dziedziny. Metoda jest oparta na ścisłej współpracy z przyszłym użytkownikiem. Nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika. Krok Sporządzenie słownika pojęć Udokumentowany w: Słownik pojęć Ustalenie aktorów Ustalenie przypadków użycia Dokument opisu aktorów Opis każdego przypadku użycia: * podział na nazwane części * wyspecyfikowanie w szczegółach * znalezienie wspólnych części w różnych przypadkach użycia Diagram przypadków użycia

27 Sporządzenie słownika pojęć Polega na wyłowieniu wszystkich terminów z początkowych wymagań. Słownik dotyczy dziedziny problemowej. Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu. Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, aktywności, zdarzeń, itd. Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika: * na rzeczowniki: mogą one oznaczać aktorów lub obiekty dziedziny problemowej * na frazy opisujące funkcje, akcje, zachowanie się: mogą one być podstawą wyróżnienia przypadków użycia.

28 Ustalenie aktorów Jaka grupa potrzebuje wspomagania ze strony systemu? Jacy użytkownicy są konieczni do tego, aby system? Funkcje należy rozbić na odnoszące się do - dziedziny przedmiotowej (np. osoba rejestrująca) i - wspomagania systemu (np. administrator systemu) Z jakiego sprzętu zewnętrznego (komputerów, sieci, itp.) musi korzystać system aby realizować swoje funkcje. Wyszukanie potencjalnych aktorów musi być powiązane z ustaleniem granic systemu, tj. odrzucenia obszarów dziedziny problemowej, którymi system nie zajmuje się.

29 Ustalenie aktorów c.d. Po wyszukaniu aktorów, należy ustalić: - czy jest to aktor konkretny (Jan Kowalski), czy też określenie roli (magazynier) -nazwę dla każdego aktora/roli - zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami (sekretarka pracownik administracji pracownik dowolna osoba). Niekiedy warto ustalić hierarchię dziedziczenia dla aktorów. -opisać relacje pomiędzy konkretnymi użytkownikami i aktorami -czy użytkownik może łączyć funkcje kilku aktorów i jakich

30 Analiza aktorów Jakie jest główne zadanie dla każdego aktora? Czy aktor będzie czytał/pisał/zmieniał informację w systemie? Czy aktor ma informować system o zmianach na zewnątrz? Użytkownik Aktor Przypadek użycia Jest związany z: Może grać rolę Jan Kowalski Administrator systemu Przeładowanie systemu Adam Malina Pracownik Wejście z kartą i kodem Gość Osoba informowana Informacja ogólna Konkretny klient Klient Wypłata z konta

31 Ustalenie przypadków użycia Dla każdego aktora, znajdź zadania i funkcje, które powinien wykonywać w związku z jego działalnością w zakresie dziedziny przedmiotowej jak i systemu informacyjnego. Staraj się powiązać w jeden przypadek użycia zespół funkcji i zadań wspólnie realizujących ten sam cel. Unikaj rozbicia jednego przypadku użycia na wiele pod-przypadków, o ile każdy z nich realizuje cel cząstkowy, który musi być uzupełniony przez inne funkcje lub zadania. Nazwy dla przypadków użycia: powinny być krótkie ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. wpłacanie pieniędzy, a nie przyjęcie pieniędzy od klienta. 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. Niektóre z powstałych w ten sposób przypadków użycia mogą być mutacjami lub szczególnymi przypadkami innych przypadków użycia. Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z nich są zbędne lub mogą być uogólnione.

32 Specyfikacja każdego PU Wyodrębnij przypadki bazowe, tj. takie, które stanowią istotę zadania lub funkcji, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne. Nazwij te przypadki bazowe ; nazwy powinny być proste i zrozumiałe. Ustal wzajemne powiązanie przypadków bazowych, poprzez ustalenie ich sekwencji, alternatywy, zależności, związku przyczyna-skutek, itd. Dodaj zachowanie skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie przypadków bazowych z tego rodzaju zachowaniem. Może ono byc także powiązane w pewną strukturę. Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku użycia nie były zbyt ogólne lub zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków wielokrotnego użycia. Struktura nie może być zbyt duża i złożona. Staraj się wyizolować bloki wielokrotnego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. Wydzielenie bloku wielokrotnego użycia może być powiązane z określeniem nieco bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.