E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 1/42 Wykład 2 Model przypadków użycia dr inż. Ewa Stemposz

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 2/42 Zagadnienia  Notacja  Analiza aktorów  Analiza przypadków użycia  Analiza relacji między przypadkami użycia  Określanie aktorów  Określanie przypadków użycia  Dokumentowanie przypadków użycia  Zadania modelu przypadków użycia Model przypadków użycia:

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 3/42 Model wymagań  Model przypadków użycia  Obiektowy model analityczny Składowe: 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.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 4/42 Notacja 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. Weryfikacja klienta Wypłata pieniędzy ud Obsługa klienta «include» Klient

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 5/42 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”. (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? (1) Czy system może być aktorem sam dla siebie? Aktor to przecież, zgodnie z definicją, byt z otoczenia systemu. (3) Aktor pasywny a interakcja z systemem ?

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 6/42 Analiza aktorów Wyjaśnienie różnicy pomiędzy pojęciem „konkretny użytkownik” a pojęciem „aktor”: Konkretny użytkownik AktorPrzypadek użycia Może grać rolę zleca Jan Kowalski Adam Malina Konkretny gość Konkretny klient Administrator systemu Pracownik Osoba informowana Klient Przeładowanie systemu Wejście z kartą i kodem Uzyskanie informacji ogólnych Wypłata z konta

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 7/42 Wykorzystanie stereotypów dla aktorów Aktor: system zewnętrzny System ubezpieczeń Aktor: czas 1-szy dzień roku Klient «actor» Klient Aktor: człowiek, grupa ludzi, organizacja Klient

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 8/42 Przykład diagramu przypadków użycia (1) 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. Klient Kasjer Wpłata pieniędzy Wypłata pieniędzy Klient ? Wpłata pieniędzy Wypłata pieniędzy alternatywna notacja dla przypadków

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 9/42 Przykład diagramu przypadków użycia (2) ud Automat do sprzedaży papierosów Zakup paczki papierosów Uzupełnienie towaru Wykonanie operacji pieniężnej Sporządzenie raportu Klient Operator Kontroler

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 10/42 Liczność związków asocjacji ud Automat do sprzedaży papierosów Zakup paczki papierosów Uzupełnienie towaru Wykonanie operacji pieniężnej Sporządzenie raportu Klient Operator Kontroler * 1 * * * *

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 11/42 Oznaczanie kierunków interakcji ud Automat do sprzedaży papierosów Zakup paczki papierosów Uzupełnienie towaru Wykonanie operacji pieniężnej Sporządzenie raportu Klient Operator System archiwizujący

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 12/42 Relacje między przypadkami użycia (1) (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 ». P1 P2 « include » (a) Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2. P2 jest nazywane przypadkiem włączanym. (b) Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P2. P2 jest nazywane 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. W obu poniższych diagramach P1, nazywane tu przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania (P2 jest wywoływane z P1).

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 13/42 Relacje między przypadkami użycia (2) P1 P2 « extend » Podział przypadku na podprzypadki jest podziałem kodu na części i jest dokonywany w celach takich jak: a) redukcja złożoności kodu, b) wyodrębnianie bloków ponownego użycia. Oba rodzaje działalności służą wspieraniu podnoszenia wydajności przy budowie produktów informatycznych. (2) Podział przypadku na podprzypadki

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 14/42 Relacje między przypadkami użycia (3) «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 «extend» jest wykorzystywane w przebiegach opcjonalnych (przypadek rozszerzający nie zawsze będzie wykonywany) − strzałka jest skierowana w stronę przypadku bazowego Naprawa samochodu Przegląd samochodu Sprzedaż samochodu Rejestracja klienta « include » Umycie samochodu « extend » Przyholowanie samochodu « extend »

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 15/42 Relacje między przypadkami użycia (4) Punkty rozszerzające (extension points) Umożliwiają podanie warunków wymaganych do użycia przypadków rozszerzających („opcjonalnych”). Umycie samochodu « extend » Przyholowanie samochodu « extend » Naprawa samochodu extension points: Samochód poza warsztatem Samochód wymaga przeglądu Przegląd samochodu extension points: Samochód jest brudny extension point: Samochód poza warsztatem extension point: Samochód wymaga przeglądu extension point: Samochód jest brudny

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 16/42 Relacje między przypadkami użycia (5) 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. Klient Dostawca Złożenie zamówienia Realizacja zamówienia « extend » Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 17/42 Związek uogólnienia między aktorami (1) 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. Osoba Gość Pracownik Księgowa Pracownik administracji

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 18/42 Związek uogólnienia między aktorami (2) Obsługa konta klienta Informowanie o stanie konta klienta Inicjalizacja karty klienta Weryfikacja karty i kodu klienta ud Automat do operacji bankowych « include » Podsystem zarządzania bazą danych banku Klient Administrator systemu

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 19/42 Związek uogólnienia między aktorami (3) Obsługa konta klienta Informowanie o stanie konta klienta Inicjalizacja karty klienta Weryfikacja karty i kodu klienta ud Automat do operacji bankowych « include » Podsystem zarządzania bazą danych banku Klient Administrator systemu

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 20/42 Rozbudowa modelu przypadków użycia 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. Klient banku Wpłać pieniądze Wypłać pieniądze Kasjer Sprawdź stan konta Weź pożyczkę Zarząd banku Klient banku Wpłać pieniądze Wypłać pieniądze Kasjer Sprawdź stan konta Weź pożyczkę Zarząd banku «include» Uaktualnianie stanu konta «include» «extend»

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 21/42 Stopień szczegółowości diagramów Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system − spojrzenia z pozycji aktorów, którzy go używają. Z założenia nie włącza zbyt wielu szczegółów, co pozwala wnioskować o funkcjonalności systemu na odpowiednio wysokim poziomie abstrakcji. Podstawowym (choć nie jedynym) zastosowaniem jest tu dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system. Edycja programu Kompilacja programu Wykonanie programu Drukowanie pliku Programista Użytkownik końcowy « include » Tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół, różni analitycy tworzą różne modele. Model zbyt szczegółowy − utrudnia analizę, zbyt ogólny − nie pozwala na wykrycie bloków ponownego użycia.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 22/42 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. 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. 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:

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 23/42 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ę.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 24/42 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.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 25/42 Kolejne kroki w konstrukcji modelu przypadków 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). Krok: Udokumentowany w: Sporządzenie słownika pojęć Słownik pojęć Określenie aktorów Określenie przypadków użycia Tworzenie opisu każdego przypadku użycia plus:  podział na nazwane części  znalezienie wspólnych części w różnych przypadkach użycia Dokument opisu aktorów Diagram przypadków użycia + dokument z opisem przypadków użycia

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 26/42 Krok 1: sporządzenie 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 lub operacji realizowanych na bytach.  Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć. Konto – służy do rejestrowania zasobów i wyników transakcji przeprowadzanych przez klienta, będącego właścicielem konta. Konta mogą być różnych typów, a w szczególności: konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto. Przykład:

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 27/42 Krok 2: określanie aktorów (1) 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 korzystać system, aby realizować swoje funkcje. Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu, tj. odrzucaniem tych obszarów dziedziny problemowej, którymi system nie będzie się zajmował (ustalenie zakresu odpowiedzialności systemu).  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. Po wyszukaniu aktorów, należy ustalić:

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 28/42 Krok 2: określanie aktorów (2) – diagram kontekstowy Podsystem zarządzania bazą danych banku Klient Administrator systemu «system» Automat do operacji bankowych

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 29/42 Krok 3: określanie przypadków użycia (1)  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. 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 ≡ zadanie zlecane systemowi ≡ przypadek użycia

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 30/42 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 C reate R ead U pdate D elete.  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, podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. 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.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 31/42 Krok 4: dokumentowanie przypadków użycia 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: Dokumentacja przypadków użycia powinna zawierać: 3. Opis szczegółowy każdego przypadku użycia:  scenariusz(e)  specyfikację uczestniczących obiektów,  diagram(y) aktywności, stanów, interakcji.  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ść,  jak i kiedy używane są pojęcia dziedziny problemowej.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 32/42 Diagram interakcji dla przypadku użycia (1) Przesyłanie komunikatów pomiędzy obiektami: k1 k2 k3 k4 k5 Obiekt 1Obiekt 2Obiekt 3Obiekt 4 ki − komunikat, czyli polecenie wykonania operacji na obiekcie, do którego komunikat jest wysyłany; komunikat nosi nazwę tej operacji czas Aktor

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 33/42 Diagram interakcji dla przypadku użycia (2) wpłata pieniędzy :Formularz :Kasa:Konto :Bank wypełnij podaj formularz aktualizuj stan zwiększ bilans zwiększ bilans wydaj pokwitowanie :Klient Uproszczony scenariusz Wypełnij formularz wpłaty Podaj formularz i gotówkę do kasy Aktualizuj stan konta klienta Zwiększ bilans kasy Zwiększ bilans banku Wydaj pokwitowanie dla klienta

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 34/42 Opis przypadku – uproszczona reguła (1) Uwaga: Chociaż nie istnieje zestandardyzowany format dokumentu opisującego przypadek użycia (w tym określającego format dla scenariuszy – w praktyce sposoby opisu różnią się od autora do autora), to można tu posłużyć się pewną uproszczoną regułą, która dzieli opis na pięć, kolejno następujących po sobie części: 1. Założenia: należy tu umieszczać warunki, które ani nie będą sprawdzane przez przypadek użycia ani też nie muszą być sprawdzane bezpośrednio przed jego wywołaniem. Przyjmuje się założenie, że w momencie wywołania warunki te będą spełnione. Do typowych warunków, umieszczanych w tej części opisu przypadku, należą autentykacja i autoryzacja. Część Założenia często nie jest umieszczana w dokumencie, ponieważ domyślnie zakłada się spełnienie jej warunków, tak aby wywołanie przypadku w ogóle było możliwe. 2. Warunek wstępny: opisuje „świat sprzed”, czyli określa warunki, których spełnienie wymaga wcześniejszego wywołania innych przypadków użycia. Spełnienie warunków umieszczonych w tej części opisu jest sprawdzane tuż przed lub od razu po wywołaniu przypadku i od wyniku sprawdzenia zależy, czy przypadek będzie dalej kontynuowany.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 35/42 Opis przypadku – uproszczona reguła (2) 3. Dialog: jak sama nazwa mówi, umieszczamy tu konwersację (tzw. przepływ zdarzeń) pomiędzy bytem wywołującym (może być nim aktor lub inny przypadek użycia) a danym przypadkiem użycia. Celem konwersacji jest pozyskanie danych potrzebnych do realizacji przypadku (nie dotyczy to tych danych, które w danym momencie są przechowywane w systemie). Dialog przybiera formę scenariuszy. 4. Zakończenie: tu opisuje się, w jaki sposób przypadek użycia jest kończony. Często wynika to bezpośrednio ze scenariusza i w takiej sytuacji część Zakończenie może być po prostu opuszczona. 5. Warunek końcowy: Opisuje „świat po”, czyli określa co będzie wykonane, zapamiętane, itd. po zrealizowaniu przypadku.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 36/42 Szablon dokumentacji przypadku użycia (1) NazwaNazwa przypadku IdIdentyfikator przypadku AutorInformacje o autorze PriorytetNp. wysoki, znaczący, umiarkowany, pomniejszy, niski lub można wykorzystać jakąś skalę (np. 0-5). TypNp. ogólny, szczegółowy AktorzyLista aktorów związanych z przypadkiem OpisKrótka charakterystyka przypadku Warunek początkowyŚwiat „przed”, czyli informacja o tym, co powinno być wykonane wcześniej (np. jakie inne przypadki), tak aby system mógł zrealizować dany przypadek. Główny przepływ zdarzeńScenariusz główny Alternatywne przepływy zdarzeń Scenariusze alternatywne ZakończenieInformacja, w jaki sposób przypadek użycia jest kończony. Warunek końcowyŚwiat „po”, czyli stan systemu po wykonaniu przypadku. Punkty rozszerzeń

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 37/42 Szablon dokumentacji przypadku użycia (2) Wymagania niefunkcjonalneNp. czas odpowiedzi, szybkość transakcji, itd. Uwagi dodatkoweWszystko, co warte jest uwagi, a nie zostało omówione powyżej; informacje biznesowe

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 38/42 Dokumentacja przypadku Wypożycz płytę DVD (1) NazwaWypożycz płytę DVD IdIdWPł7 AutorJan Kowalski - analityk PriorytetWysoki TypSzczegółowy AktorzyPracownik wypożyczalni OpisPrzypadek dotyczy rejestracji wypożyczenia płyt DVD; płyty przeznaczone dla dorosłych można wypożyczać od 18-tego roku życia; jednocześnie można mieć wypożyczonych co najwyżej 5 płyt; nie wolno wypożyczać osobie, która aktualnie znajduje się w okresie karencji Warunek początkowyPowinna być zarejestrowana co najmniej jedna płyta DVD

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 39/42 Dokumentacja przypadku Wypożycz płytę DVD (2) Główny przepływ zdarzeń1.Pracownik wypożyczalni uruchamia przypadek Wypożycz płytę DVD. 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ł. Alternatywne przepływy zdarzeń 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 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 płyty 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.

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 40/42 Dokumentacja przypadku Wypożycz płytę DVD (3) Alternatywne przepływy zdarzeń, cd. 3c Jeśli osoba wypożyczająca ma już aktualnie co najmniej pięć wypożyczonych płyt 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. ZakończeniePrzypadek może być skończony w dowolnym momencie. Warunek końcowyO ile warunki wypożyczenia zostały zrealizowane, to powinny zostać zarejestrowane następujące informacje o wypożyczeniu płyty : kto wypożyczył, co wypożyczył i kiedy wypożyczył Punkty rozszerzeń Wymagania niefunkcjonalne Uwagi dodatkowe

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 41/42 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. Przypadki użycia powinny odwzorowywać strukturę systemu tak, jak tę strukturę widzą przyszli użytkownicy systemu.  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,  dostarczenie środków umożliwiających weryfikację poprawności i kompletności projektu. Ponadto, model przypadków użycia pozwala na:

E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 42/42 Przypadki użycia w analizie Eksperci Użytkownicy Doświadczenie w dziedzinie przedmiotowej Przypadki użycia Model dziedziny Model zastosowania Model analityczny mocny wpływ słaby wpływ