Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Transkrypt

1 Analiza i projektowanie obiektowe 2015/2016 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. 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 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 Cel 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 13