Analiza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia

Transkrypt

1 Analiza i projektowanie obiektowe 2017/2018 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2. Pozyskiwanie przypadków użycia. 3. Diagram przypadków użycia. 4. Relacje między przypadkami użycia 2 1

2 Czym są przypadki użycia 3 Dlaczego przypadki użycia Przypadki użycia są szeroko rozpowszechnionym mechanizmem znajdowania oraz opisywania wymagań (szczególnie wymagań funkcjonalnych), wpływają one na sposób prowadzenia projektu informatycznego, w tym na sposób prowadzonej analizy obiektowej i projektowania obiektowego (OOA/D). Technika przypadków użycia została wprowadzona przez Ivara Jacobsona w 1992 roku. Pisanie przypadków użycia czyli opowieści o używaniu systemu jest doskonałą metodą zrozumienia i zapisania wymagań. Kluczowym elementem przy pracy nad przypadkami użycia jest skoncentrowanie się na pytaniu W jaki sposób przy użyciu systemu można osiągnąć cele użytkownika niż skoncentrowanie się jedynie na sporządzeniu listy funkcjonalności tworzonego systemu. 4 2

3 Podstawowe pojęcia (1) Aktor byt w systemie, który posiada zachowanie: osoba identyfikowana przez swoją rolę (np. kierownik, klient,), system komputerowy lub organizacja. Przypadek użycia (ang. use case) reprezentuje sekwencję akcji i interakcji pomiędzy aktorami i tworzonym systemem. Zapisywany jest jako opowieść dotycząca używania wybranego fragmentu systemu. Przypadek użycia jest zbiorem powiązanych scenariuszy (kończących się sukcesem, bądź porażką) opisujących zachowanie się aktorów wykorzystujących system w celu osiągnięcia określonego celu. Przypadek użycia powinien opisywać takie zachowania systemu, które dostarczają konkretnemu aktorowi obserwowalne i istotne wyniki. 5 Podstawowe pojęcia (2) Przypadki użycia są wykorzystywane przede wszystkim do opisywania wymagań funkcjonalnych (opis tego co system robi). Używanie techniki przypadków użycia (szczególnie w metodyce UP) ma zadanie ograniczyć stosowanie formularzy zawierających listy funkcjonalności opisujących co system powinien robić. Przypadki użycia są dokumentami tekstowymi, a nie diagramami. Proces modelowania przypadków użycia to proces pisania tekstu, a nie tworzenia diagramów. Diagramy przypadków użycia dostępne w UML mają za zadanie jedynie zilustrować przypadki użycia (aktorzy i związki pomiędzy aktorami). 6 3

4 Przypadków użycia, a analiza i projektowanie obiektowe W przypadku tworzenia przypadków użycia przyjmowane jest podejście czarnej skrzynki (ang. black box) opisywane są odpowiedzialności (ang. responsibility) systemu, a nie opisywanie tego jak działa system, bądź jego komponenty. Podejście to nawiązuje do paradygmatu obiektowego w którym obiekty programowe posiadają odpowiedzialność (ang. responsibility) i współpracują z innymi obiektami też posiadającymi swoją odpowiedzialność. Przypadki użycia dotyczą fazy analizy obiektowej (która odpowiada na pytanie co system robi: what ), bez konieczności rozstrzygania tego co jest realizowane w fazie projektowania obiektowego (odpowiedź na pytanie jak system działa: how ). 7 Sposoby zapisu przypadków użycia Opis skrócony (ang. brief) opis zajmujący jeden paragraf, przeważnie zawiera jedynie podstawowy scenariusz kończący się sukcesem. Opis nieformalny (ang. casual) opis wielu scenariuszy w postaci nieformalnej. Opis pełny (ang. fully dressed) opis najbardziej pogłębiony. Wszystkie kroki i warianty są zapisane w postaci szczegółowej, pojawiają się sekcje uzupełniające np. z warunkami początkowymi. 8 4

5 Przykład: opis skrócony Przykład dotyczy programu tworzenia aplikacji obsługującej klienta w sklepie w oparciu o terminal wielozadaniowy POS (point-of-sale) Przypadek użycia Obsługa sprzedaży Klient przychodzi do kasy z produktami, które pragnie nabyć. Kasjer używa POS do wpisania każdego produktu. System wyświetla kwotę globalną zakupów oraz szczegółowe informacje o poszczególnym produkcie. Klient wprowadza informacje o sposobie realizowania płatności, które są weryfikowane i zapisywane przez system. System uaktualnia stany magazynowe. Klient otrzymuje paragon i wychodzi z produktami, które nabył. 9 Przykład: opis pełny Opis pełny zawiera więcej szczegółów oraz jest ustrukturyzowany. Opis tego rodzaju pozwala na pełne zrozumienie celów użytkownika, zadań i wymagań. Opisy pełne mogą być zapisywane w szablonach różnego rodzaju. Analiza opisu pełnego przypadku użycia Obsługa sprzedaży 10 5

6 Elementy składowe opisu pełnego (1) Aktor podstawowy (primary actor): Podstawowy aktor, który żąda różnych usług systemu, aby osiągnąć zaplanowane cele użytkownika. Główni odbiorcy i oczekiwania względem systemu: punkt określający granice w których działa system. Pozwala na opisanie oczekiwań względem systemu przez wszystkich jego użytkowników. Warunki wstępne: Stan systemu, który musi być zawsze prawdziwy, aby móc rozpocząć scenariusz danego przypadku użycia, Nie są to warunki wstępne, które są testowane wewnątrz danego przypadku użycia, zakłada się że są one spełnione wcześniej, W większości wypadków stan ten jest osiągnięty po zrealizowaniu scenariusza innego przypadku użycia. Warunki końcowe: stan systemu, który musi zachodzić po zakończeniu przypadku użycia tzn. jego scenariusza głównego, bądź dowolnej ścieżki alternatywnej. 11 Elementy składowe opisu pełnego (2) Cele scenariusza głównego (ścieżka podstawowa): Opis typowej ścieżki, która spełnia oczekiwania względem systemu głównych jego odbiorców (tzw. happy path ), Powinna być zapisana w sposób prosty nie zawierający odgałęzień i warunków, Warunki i odgałęzienia powinny być zapisywane w sekcji Rozszerzenia. Scenariusz główny służy do zapisu następujących kroków: Interakcji pomiędzy aktorami, Walidacji danych, Zmian stanów systemu (np. modyfikowanie lub zapisywanie dowolnych wartości). Rozgałęzienia (ścieżki alternatywne): wskazują inne możliwe ścieżki, w tym te kończące się sukcesem oraz porażką. 12 6

7 Elementy składowe opisu pełnego (3) Wymagania specjalne: pozwalają na opisanie wymagań niefunkcjonalnych dotyczących wydajności, niezawodności, odporności, przenośności tworzonego systemu oraz ograniczeń nakładanych na jego architekturę. Wymagania technologiczne oraz ograniczenia na wprowadzane dane: ograniczenia technologiczne oraz ograniczenia na wprowadzane dane, które powinny są narzucone na system ze względu na kontekst w którym jest on tworzony. 13 Pozyskiwanie przypadków użycia 14 7

8 Poziom szczegółowości przypadków użycia Problemem przy tworzeniu przypadków użycia jest rozstrzygnięcie na jakim poziomie szczegółowości należy je określać. Przyjmuje się, że przy opisie przypadków użycia należy koncentrować się na poziomie elementarnych procesów biznesowych definiowanych jako: Zadanie wykonane przez osobę w jednym miejscu i w jednym czasie w odpowiedzi na określoną potrzebę biznesową, która wprowadza obserwowalną i mierzalną wartość istotną z punktu widzenia rozpatrywanego kontekstu. Przyjmuje się, że elementarny proces biznesowy to proces trwający od kilkunastu sekund do godziny. Co jest, a co nie jest przypadkiem użycia: Negocjacja kontraktu z dostawcą (nie), Obsługa zwrotów towaru (tak), Złożenie zamówienia (tak), Zalogowanie się do systemu (nie), Wydrukowanie dokumentu (nie). 15 Przypadki użycia i cele użytkownika Aktorzy posiadają pewne cele (potrzeby) i używają aplikacji do ich osiągania. Poziom elementarnych procesów biznesowych jest nazywany poziomem celów użytkownika (user goal-level). Znajdowanie przypadków użycia powinno być realizowane według zasady: Znajdź cele użytkownika, Zdefiniuj przypadek użycia dla każdego z nich. Powyższe sprowadza problem znajdowanie przypadków użycia do zadawania pytania Jakie są cele systemu? a nie Jakie wyróżniamy przypadki użycia?. Dla celu: zachowaj informacje o obsłudze sprzedaży wprowadzany jest przypadek użycia Obsluga Sprzedaży. Strategia przy poszukiwaniu przypadków użycia powinna polegać każdorazowo na znajdowaniu celów wyższego poziomu dla celów pojawiających się w trakcie analizy. Pozwoli to na zidentyfikowanie elementarnych procesów biznesowych oraz pozwoli je odróżnić od celów drugorzędnych oraz ogólnych celów biznesowych. 16 8

9 Zasady znajdowania aktorów podstawowych, celów użytkownika oraz przypadków użycia Przypadki użycia są definiowane w taki sposób, aby spełniać cele aktorów podstawowych. W związku z powyższym procedura postępowania w celu ich identyfikacji jest następująca: Określenie granic systemu (czy rozważana jest aplikacja, aplikacja + hardware traktowane jako jedna jednostka, cała organizacja), Identyfikacja aktorów podstawowych użytkownicy posiadający cele które mogą być osiągnięte poprzez używanie poszczególnych funkcjonalności systemu, Dla każdego z nich należy zidentyfikować cele użytkownika należy je rozpatrywać na najwyższym poziomie spełniającym założenia elementarnych procesów biznesowych, Zdefiniowanie przypadków użycia, które spełniają cele użytkowników. 17 Krok 1: Określanie granic systemu W przypadku problemów z określeniem granic systemu konieczne jest określenie tego co znajduje się poza nim tzn. konieczne jest określenie zewnętrznych aktorów podstawowych i drugoplanowych. W przypadku przykładu POS system sam w sobie jest systemem, który budujemy. Poza systemem znajdują się Kasjer, Serwis Autoryzacji Transakcji, itd. 18 9

10 Krok 2 i 3: Identyfikacja aktorów podstawowych oraz ich celów (1) Etapy identyfikacji aktorów podstawowych oraz określania ich celów jest realizowane jednocześnie. Poniższe pytania pozwalają na identyfikację aktorów i celów użytkownika: Kto uruchamia i zatrzymuje system? Kto realizuje politykę bezpieczeństwa i zarządzania użytkownikami? Czy jest proces monitoringu, który ma za zadanie restartować system po jego zawieszeniu? Jak realizowany jest update systemu? Kto administruje systemem? Czy czas jest aktorem tzn. czy system wykonuje jakieś działania w określonych okresach czasu? Kto analizuje logi systemowe? 19 Krok 2 i 3: Identyfikacja aktorów podstawowych oraz ich celów (2) Przy szukaniu aktorów podstawowych należy uwzględniać zewnętrzne systemy komputerowe. W celu powiązania aktorów podstawowych z celami tworzone są listy aktor-cel: Aktor Kasjer Manager Administrator systemu System aktywności sprzedaży Cel Obsługa sprzedaży Obsługa zwrotu towarów Obejmowanie stanowiska pracy Zwalnianie stanowiska pracy Uruchomienie systemu Zatrzymanie systemu Zarządzanie użytkownikami Zarządzanie bezpieczeństwem Analiza sprzedaży 20 10

11 Krok 2 i 3: Identyfikacja aktorów podstawowych oraz ich celów (3) Aktorzy podstawowi i cele użytkownika ściśle zależą od granic systemu! Określenie czy dany aktor jest aktorem podstawowym zależy od tego jak zostały określone granice systemu. Dla systemu POS aktorem podstawowym realizującym cel Obsluga sprzedaży jest aktor Kasjer. Inni aktorzy: System Aktywności Sprzedaży (cel: Analiza sprzedaży), Klient (cel: Kupowanie produktów), Urząd Skarbowy (cel: Pobieranie podatków). 21 Krok 4: Zdefiniowanie przypadków użycia Przypadki użycia należy nazywać w sposób podobny do celów użytkownika, nazwy powinny zaczynać się od czasownika. W przypadku ogólnym tworzony jest jeden przypadek użycia dla jednego celu użytkownika. Wyjątkiem jest tworzenie jednego przypadku użycia dla tzw. celów CRUD (create, retrive, update, delete) np. cele Edytowanie użytkownika i Usuwanie użytkownika powinny zostać zapisane w przypadku Zarządzanie Użytkownikami

12 Aktorzy Aktorem jest dowolny byt posiadający zachowanie, włączając w to system który modelujemy. Aktorami mogą być ludzie, organizacje, inne systemy, maszyny. Rodzaje aktorów: Aktor podstawowy posiada cele użytkownika realizowane poprzez używanie funkcjonalności systemu, który modelujemy (np. Kasjer) Dlaczego wyróżniamy? aby znaleźć cele użytkownika, które są podstawą do tworzenia przypadków użycia. Aktor wspomagający udostępnia usługi (np. informacje) do systemu, który modelujemy (np. System Autoryzacji Płatności) Dlaczego wyróżniamy? aby doprecyzować zewnętrzne interfejsy i protokoły. Aktorzy zewnętrzni posiadają określony cel w zachowaniu opisywanym przez przypadek użycia, ale nie są aktorami podstawowymi, ani wspomagającymi (np. Urząd Skarbowy) Dlaczego wyróżniamy? aby opisać wszystkie oczekiwania względem systemu. 23 Diagram przypadków użycia 24 12

13 Diagram przypadków użycia w UML Granice systemu POS Komunikacja Aktor Kasjer Obsługa sprzedaży Obsługa zwrotu towarów Obejmowanie stanowiska pracy System autoryzacji płatności << actor >> System obliczania podatków << actor >> System aktywności sprzedaży Analiza sprzedaży << actor >> System księgowy Zarządzanie użytkownikami << actor >> System HR Administrator systemu Zarządzanie bezpieczeństwem Przypadek użycia 25 Relacje pomiędzy przypadkami użycia 13

14 Relacje pomiędzy przypadkami użycia: wprowadzenie Pomiędzy przypadkami użycia można określać relacje zależności. Relacje te nie mają wpływu na to co dany przypadek użycia opisuje (nie wpływają na jego zachowanie). Są wprowadzane po to, aby grupować przypadki użycia w większe struktury, ułatwiać zarządzanie wymaganiami oraz komunikację pomiędzy analitykami. Wyróżnia się następujące relacje pomiędzy przypadkami użycia: Relacja include, Relacja extend, Relacja generalizacji. Relacja include Relacja include to podstawowa i najczęściej wykorzystywana relacja pomiędzy przypadkami użycia. Relacja ta opisuje sytuacje, w których pewne cechy powtarzające się w różnych przypadkach użycia zostają przeniesione do nowego przypadku użycia. Nowy przypadek użycia zawiera się w przypadkach wyjściowych. Zamiast wprowadzania relacji include można powielać tekst opisujący powtarzające się cechy w sekcji Rozszerzenia każdego z przypadków wyjściowych. Wprowadzenie nowego przypadku użycia pozwala jednak uniknąć duplikowania tekstu. Relacje include powinna być wprowadzana gdy: Te same opisy powtarzają się w więcej niż dwóch przypadkach użycia, Przypadki użycia są złożone i skomplikowana, podział na logiczne części zwiększy czytelność wymagań do systemu. 14

15 Relacja include: przykład (1) Use Case 1: Obsługa Sprzedaży Scenariusz główny: 1.Klient przychodzi do POS z towarami i/lub usługami, które chce nabyć 7. Klient płaci i system zachowuje informację o płatności Rozszerzenia: 7a. Klient płaci gotówką 7b. Klient płaci czekiem: Płatność czekiem (UC 10) 7c. Klient płaci kartą: Płatność kartą (UC 9) Use Case 5: Obsługa Wynajmu Rozszerzenia: 5b. Klient płaci kartą: Płatność kartą (UC 9) Use Case 9: Płatność kartą Scenariusz główny: 1.Klient podaje dane dotyczące identyfikacji karty 2.System przesyła dane i prośbę o autoryzację płatności do Systemu Autoryzacji 3. System otrzymuje autoryzację płatności Rozszerzenia: 2a. System wykrywa błędy komunikacji z Systemem Autoryzacji Relacja include Relacja include: przykład (2) 15

16 Relacja include w obsłudze zdarzeń asynchronicznych Relacja include może być wykorzystywana jest do opisywania zdarzeń asynchronicznych zachodzących w systemie. Przez zdarzenie asynchroniczne rozumiemy takie zachowanie użytkownika systemu, które może pojawić się w dowolnym momencie bez konieczności trzymania się narzucanej przez scenariusz główny kolejności np. możliwość wywołania okna z pomocą itp. Relacja include wprowadzana jest w tej części rozszerzeń przypadku użycia, która oznaczona jest *: Use Case 9: Płatność czekiem Rozszerzenia: *b. W dowolnym momencie kasjer może odwołać się do pomocy kontekstowej: Pomoc kontekstowa (UC 12) *c. W dowolnym momencie kasjer może wezwać managera: Wezwanie Managera (UC 13) *d. W dowolnym momencie kasjer może zablokować kasę: Blokada kasy (UC 20) Relacja extend Relacja extend opisuje sytuacje, w których bazowy przypadek użycia (base use case) jest uzupełniony (powiększony) poprzez rozszerzający przypadek użycia (extension use case; extending use case). Bazowy przypadek użycia określa tzw. punkt rozszerzenia (extension point), czyli punkt w którym włączane są rozszerzenia. Rozszerzający przypadek użycia określa warunki, które muszą zajść aby został włączony do przypadku bazowego. Wykonanie przypadku rozszerzającego sprowadza się do realizacji następujących kroków: 1. Wykonanie przypadku bazowego do punktu rozszerzenia, 2. Sprawdzenie czy zachodzą warunki zapisane w przypadku rozszerzającym, 3. Jeżeli zachodzą, następuje wykonanie kroków zapisanych w przypadku rozszerzającym 4. Przejście do wykonania dalszych kroków z przypadku bazowego. 16

17 Relacja extend: przykład 1 (1) Use Case 1: Obsługa sprzedaży Bazowy przypadek użycia Punkty rozszerzenia: Obsługa klienta typu VIP, krok 1; Obsługa płatności przy pomocy bonu towarowego, krok 7 Scenariusz główny: 1.Klient przychodzi do POS z towarami i/lub usługami, które chce nabyć 7. Klient płaci i system zachowuje informację o płatności Rozszerzający przypadek użycia Use Case 23: Obsługa płatności przy pomocy bonów towarowych Trigger: Klient chce płacić przy pomocy bonu towarowego Scenariusz główny: Klient podaje bon towarowy kasjerowi Kasjer sprawdza ważność bonu i jego rodzaj Kasjer sprawdza jakie towary mogą być sprzedane przy pomocy bonu Relacja extend: przykład 1 (2) 17

18 Relacja extend: przykład 2 Relacja extend: dyskusja W wielu sytuacjach punkt rozszerzenia może być określony jako dowolne miejsce w scenariuszu głównym. Dotyczy to w szczególności systemów w których pojawia się wiele zdarzeń asynchronicznych (zdarzenia wywoływane w dowolnym miejscu scenariusza głównego). Relacja znajduje zastosowanie, gdy z pewnych względów nie jest możliwe wpisanie rozszerzeń wprost do przypadku bazowego (np. dany przypadek nie jest uznawany za stabilny przez analityków pracujących nad wymaganiami, wprowadzenie zmian wymusiłoby zmiany w innych przypadkach). Dzięki relacji extend przypadek bazowy nie ma odniesień do przypadku rozszerzającego pozostaje niezmieniony. Relacja extend może być zastąpiona relacją include, bądź może zostać sprowadzona do włączenia ścieżki rozszerzającej wprost do przypadku bazowego. Podejścia takie wymagają jednak modyfikacji przypadku bazowego. 18

19 Relacja generalizacji Relacja generalizacji pomiędzy specjalizowanym przypadkiem użycia, a przypadkiem użycia generalizacją oznacza, że specjalizowany przypadek użycia posiada takie samo zachowanie jak przypadek generalizacja, ponadto posiada dodatkową informację (dodatkowe kroki w scenariuszu). Specjalizowany przypadek użycia może występować zamiast przypadku generalizacji, realizuje dokładnie te same kroki co przypadek generalizacja. Relacja generalizacji: przykład 19

20 Relacje pomiędzy przypadkami użycia: dyskusja Podczas zbierania wymagań przy pomocy przypadków użycia należy zawsze pamiętać, że kluczowym aspektem tego procesu jest pisanie tekstu dla poszczególnych przypadków użycia, a nie koncentrowanie się na budowanie złożonych diagramów precyzyjnie opisujących relacje pomiędzy nimi. Potrzeba wprowadzenia relacji pomiędzy przypadkami użycia pojawi się w naturalny sposób podczas ich pisania relacje te ułatwiały nam będą wyrażanie pewnych zależności pomiędzy nimi. Przyjmuje się, że bez ograniczeń można wprowadzać relację include. Zwiększa ona zawsze czytelność wymagań. Wprowadzanie relacji extend i generalizacji bardzo często zmniejsza czytelność wymagań przy jednoczesnym bardzo dużym narzucie czasowym potrzebnym na ich wprowadzenie. 20