APIO. W5 PRZYPADKI UŻYCIA. SCENARIUSZE PISANIE SCENARIUSZY RÓŻNE PODEJŚCIA RÓŻNE SZABLONY. dr inż. Grażyna Hołodnik-Janczura W8/K4

Transkrypt

1 APIO. W5 PRZYPADKI UŻYCIA. SCENARIUSZE PISANIE SCENARIUSZY RÓŻNE PODEJŚCIA RÓŻNE SZABLONY dr inż. Grażyna Hołodnik-Janczura W8/K4

2 LITERATURA PODSTAWOWA 1. Cockburn A., Jak pisać efektywne przypadki użycia, WNT, W-wa Cohn M.: Succeeding with Agile. Software Development Using Scrum, Addison- Wesley, Michigan 2010 Ferguson Smart J., BDD w działaniu, Helion Leffingwell D., Widrig D., Zarządzanie wymaganiami, WNT, W-wa Robertson S., Roberston J., Mastering the Requirements Process, Addison-Wesley, Schneider G., Winters J., Stosowanie przypadków użycia, WNT, W-wa 2004 GHJ-PWR 2

3 OBIEKTOWE PODEJŚCIE DO TWORZENIA OPROGRAMOWANIA Pod koniec lat 80-tych i w latach 90-tych w inżynierii oprogramowania nastąpił rozwój modelowania obiektowego i metod obiektowego wytwarzania: Metoda Grady ego Boocha Booch Method (Rational Software) Metoda Jamesa Rumbaugha - Object Modeling Technique Metoda Ivara Jacobsona Objected Oriented Software Engineering Metoda Petera Coada i Eda Yourdona Coad-Yourdon Method i wiele innych. Wiele różnych koncepcji zostało uzgodnionych za pomocą wprowadzenia ujednoliconego języka modelowania UML (Unified Modeling Language) GHJ-PWR 3

4 ANALIZA SYSTEMU INFORMACYJNEGO W PODEJŚCIU OBIEKTOWYM Z pięciu perspektyw biznesowa biznesowe i produktowe przypadki użycia (obraz systemu widzianego przez użytkownika) projektowa dane i funkcje widziane z wnętrza systemu (struktura statyczna) procesowa dynamiczne aspekty systemu implementacyjna sposób konstrukcji statycznych i dynamicznych aspektów systemu wdrożeniowa związki statycznych i dynamicznych aspektów systemu ze środowiskiem, w którym będzie wdrożony GHJ-PWR 4

5 MODELE OBIEKTOWE KOMPONENTY UML-A Diagram przypadków użycia Diagram klas Diagram obiektów Diagram stanów Diagram przebiegu Diagram czynności Diagram kooperacji Diagram komponentów Diagram wdrożenia Pakiety GHJ-PWR 5

6 BIZNESOWE PRZYPADKI UŻYCIA (BPU) Wymagania dla tworzonego systemu informatycznego (produktu) są opisywane na podstawie pracy wykonywanej w badanym obszarze działalności, podzielonej na biznesowe przypadki użycia (BPU). Pojedynczy BPU jest wyodrębniony spośród innych biznesowych przypadków użycia. Złożony, może być podzielony na mniejsze. BPU Jest podstawową jednostką pisania wymagań funkcjonalnych i niefunkcjonalnych za pomocą obiektowych technik modelowania wizualnego. Biznesowy przypadek użycia odnosi się do działań wykonywanych przez organizację w odpowiedzi na zdarzenia biznesowe oraz interakcje między zidentyfikowanymi obiektami. BPU odbywa się w czasie: po wystąpieniu zdarzenia (ang. trigger) powinny być wykonane działania zgodnie z logiką przepływu pracy. Koniec BPU oznacza, że: wszystkie funkcjonalności zostały przeprowadzone, wszystkie dane używane przez BPU zostały zapisane w magazynach danych i wszystkie sąsiadujące systemy zostały powiadomione. Wspólną częścią BPU są przechowywane dane. GHJ-PWR 6

7 SYSTEMY SĄSIADUJĄCE [4, S. 79] Systemy sąsiadujące z pracą, która jest badana w celu dostarczenia nowego systemu informatycznego. Stanowią takie części tej pracy, które dostarczają informację lub otrzymują informacje/usługę. Mogą być organizacją, pojedynczym obiektem, systemem komputerowym lub inną technologią, lub ich kombinacją, mogą też uczestniczyć w działaniach opisywanych przez biznesowy przypadek użycia. Kategorie systemów sąsiadujących System aktywny (dynamiczny) występuje w interakcji lub uczestniczy w wykonywaniu pracy, zazwyczaj to jest człowiek. Przykład: klient banku jest interaktywnym systemem. System autonomiczny działa niezależnie, ale ma związek z badanym zakresem pracy, obiekt zewnętrzny taki, jak inna organizacja lub klient bez bezpośredniej interakcji - jednostronny przepływ informacji. System współpracujący zachowuje się przewidywalnie, gdy zostanie wywołany, współpraca z nim odbywa się w trakcie wykonywania przypadku biznesowego, działa na zasadzie proste pytanie odpowiedź, może być innym automatycznym systemem zawierającym bazę danych, która jest dostępna lub zapisywana przez tę pracę, np. system operacyjny lub inny system dostarczający przewidywalną lub bezpośrednią usługę dla tej pracy, np. pytanie o temperaturę, czy godzinę. GHJ-PWR 7

8 SYSTEMOWE (PRODUKTOWE) PRZYPADKI UŻYCIA (PPU) Produktowy przypadek użycia jest częścią albo całym biznesowym przypadkiem użycia. Ta część odpowiedzi na zdarzenie biznesowe, która jest obsługiwana przez automatyczny system jest produktowym przypadkiem użycia. Produktowe przypadki użycia określają zakres systemu informatycznego. Jasny i jednoznacznego opis interakcji użytkowników z systemem wspomaga koncepcja aktora. Z powodów technicznych, implementacja biznesowego przypadku użycia może składać się z kilku produktowych przypadków użycia. Wówczas tworzone są konstrukcje <<include>> oraz <<extend>>. GHJ-PWR 8

9 RELACJA: BADANY OBSZAR DZIAŁALNOŚCI (PRACA) BIZNESOWY PU (BPU) PRODUKTOWY PU (PPU) ZAKRES SYSTEMU (GRANICA PRODUKTU) [NA PODSTAWIE 5, S. 88] BPU PPU Praca Proces 1 Proces 2 Magazyn danych Proces 3 Przepływ informacji Nazwa PPU1 Granica GHJ-PWR Nazwa PPU2 produktu 9 Aktor

10 KOMENTARZ DO RYSUNKU: RELACJE Zdarzenie biznesowe pojawia się w systemie sąsiadującym i wysyła informację do organizacji, Organizacja odpowiada, wykonując w odpowiedzi pracę biznesowy przypadek użycia (BPU). Analityk wymagań i interesariusze projektu podejmują decyzję jaka część BPU będzie wspomagana przez projektowany system informatyczny (produkt) produktowy przypadek użycia. Cokolwiek jest bezpośrednio poza zakresem produktu staje się aktorem, który manipuluje funkcjonalnością produktowego przypadku użycia. GHJ-PWR 10

11 CEL TWORZENIA PRZYPADKÓW UŻYCIA (USE CASES) 1. Są podstawą pisania wymagań użytkownika dla opracowywanego systemu informatycznego. Dla każdego produktowego przypadku użycia analityk pisze wymagania funkcjonalne i operacyjne, stawiane systemowi informatycznemu, zatwierdzone wspólnie przez użytkowników i zespół twórców oprogramowania. System informatyczny nie zmienia prawdziwej natury pracy, ale zmienia sposób jej wykonania. 2. Służą do testowania zgodności nowego systemu z potrzebami użytkownika. GHJ-PWR 11

12 ETAPY OPRACOWYWANIA PRZYPADKÓW UŻYCIA Określenie funkcjonalności systemu, która musi być dostarczona Etap I opis procesów biznesowych za pomocą biznesowych przypadków użycia Etap II opis wymagań stawianych projektowanemu systemowi za pomocą produktowych przypadków użycia na podstawie biznesowych przypadków użycia Etapy są realizowane iteracyjnie, zaczynając od opisu na poziomie ogólnym, a kończąc na wystarczającym poziomie szczegółowości do rozpoczęcia projektowania, a następnie pisania kodu oprogramowania Ogólny opis systemu - opis zakresu systemu Rozpoznanie i krótki opis aktorów Rozpoznanie i krótki opis przypadków użycia Utworzenie słownika dziedzinowego Uszczegółowienie ogólnego opisu aktorów, przypadków użycia i aktualizacja słownika dziedzinowego GHJ-PWR 12

13 AKTORZY I UŻYTKOWNICY Przypadek użycia jest uruchamiany przez: aktora głównego, urzędnika, który to robi w imieniu kogoś innego (klient telefonuje, żeby złożyć zamówienie dopiero w systemie elektronicznych zamówień klient będzie aktorem głównym przez predefiniowany czas? brak interakcji eliminuje czas jako aktora, jednakże w niektórych podejściach jest aktorem Przypadek użycia może być wykorzystywany przez różnych aktorów, wówczas tworzy się tabelę aktor rola Użytkownik i inne systemy oczekują usług od analizowanego systemu należy ich traktować jako aktorów Opis typowych, wzajemnych oddziaływań aktorów z systemem produktowe przypadki użycia GHJ-PWR 13

14 PROFIL AKTORA OPIS AKTORA [1, S. 85] Klient Nazwa Urzędnik ds. zwrotów Menedżer Synoni m Profil: przeszłość i umiejętności Osoba z ulicy, zdolna do korzystania z ekranu dotykowego. Może mieć kłopoty z czytaniem, być krótkowidzem albo daltonistą. Osoba pracująca cały czas z oprogramowaniem. Pisze biegle na klawiaturze. Może chcieć możliwości dostosowywania swojego interfejsu. Używa oprogramowania od czasu do czasu, lubi graficzny interfejs. Niecierpliwy. GHJ-PWR 14

15 KONCEPCJA I IDENTYFIKACJA AKTORÓW [5, S. 14] Aktor: to jest rola, jaką odgrywa użytkownik lub urządzenie (każdy podmiot, czy system sąsiadujący), który komunikuje się z systemem: ludzie, maszyny, inne systemy korzystające z interfejsów modelowanego oprogramowania, znajdujące się na zewnątrz organizacji lub wyznaczonego zakresu pracy, a także wewnątrz organizacji, ale nie jest wewnętrznym elementem systemu. Identyfikacja aktorów poprzez zadawanie pytań: Kto korzysta z systemu? Kto instaluje system? Kto uruchamia system? Kto pielęgnuje system? Kto wyłącza system? Jakie inne systemy korzystają z tego systemu? Kto pobiera informacje z tego systemu? Kto dostarcza systemowi informacji? Czy aktualnie coś dzieje się automatycznie? GHJ-PWR 15

16 DIAGRAM PRZYPADKÓW UŻYCIA (DPU) DPU w języku UML służy do reprezentacji wymagań stawianych systemowi, opisuje system (produkt) na różnych poziomach abstrakcji Podstawowe elementy DPU Aktor podstawowy (główny) bezpośrednio i często komunikuje się z systemem, używa jego najważniejszych funkcji i odnosi największe korzyści z jego stosowania Aktor drugorzędny (pomocniczy) wspiera pracę systemu i umożliwia działanie aktorów podstawowych, aktor zewnętrzny, który wykonuje usługi dla analizowanego systemu, np. drukarka, usługa WWW, osoba dostarczająca systemowi jakieś wyniki badań Przypadek użycia z nazwą Związki - między aktorami i przypadkami użycia: asocjacja, uogólnienie dziedziczenie, dołączenie (include), rozszerzenie (extend) GHJ-PWR 16

17 NOTACJA GRAFICZNA PRZYPADKÓW UŻYCIA PU 1 <<include>> PU 4 Aktor 1 PU 2 Uogólnienie/dziedziczenie PU 5 Aktor 3 <<extend>> PU3 GHJ-PWR 17 Aktor 2

18 PRZYPADKI UŻYCIA Z DOŁĄCZENIEM <<INCLUDE>> Student Przeglądaj Ustal kartę zapisów status studenta <<include>> Zapis na wymagane kursy Przeglądaj katalog kursów Katalog kursów Profesor Wybierz kurs do prowadzenia GHJ-PWR 18

19 PRZYPADKI UŻYCIA Z ROZSZERZENIEM <<EXTEND>> Student Przeglądaj kartę zapisów <<include>> Zapis na wymagane kursy Ustal status studenta Katalog kursów Profesor Przeglądaj katalog kursów Wybierz kurs do prowadzenia Oblicz sumaryczną liczbę godzin profesora <<extend>> GHJ-PWR 19

20 PRZYPADKI UŻYCIA Z DZIEDZICZENIEM (JEST RODZAJU) <<IS A>> Student Administrator Przeglądaj kartę zapisów Zapis na wymagane kursy <<include>> Ustal status studenta Katalog kursów Profesor Przeglądaj katalog kursów Wybierz kurs do prowadzenia Oblicz sumaryczną liczbę godzin profesora <<extend>> GHJ-PWR 20

21 SCENARIUSZ SZABLON PRZYPADKU UŻYCIA W UML Opis kolejnych kroków interakcji użytkownika z aplikacją Forma: nieformalny tekst, lista ponumerowanych kroków, tabela, schemat blokowy, sieci Petriego Elementy scenariusza: {inicjator, akcja (zdarzenie), uczestnik} Inicjator obiekt zgłaszający zapotrzebowanie na usługę (wysyła komunikat) Akcja zgłoszenie zapotrzebowania Uczestnik obiekt obsługujący zgłoszenie Rodzaje scenariuszy podstawowy optymistyczny alternatywny cos może się nie udać z wyjątkami może wystąpić błąd Liczba scenariuszy zależy od wielkości aplikacji i liczby testów, które należy wykonać do sprawdzenia gotowego systemu GHJ-PWR 21

22 STRUKTURA SCENARIUSZA Warunki wstępne zdarzenie inicjujące Ciąg (przebieg) zdarzeń podstawowych i/lub nadzwyczajnych Warunki końcowe muszą być spełnione niezależnie od tego, który wariant jest realizowany, czy nadzwyczajny ciąg zdarzeń GHJ-PWR 22

23 SCENARIUSZ OPTYMISTYCZNY PODSTAWOWY CIĄG ZDARZEŃ PU: ZAPIS NA WYMAGANE KURSY Warunki wstępne: Student z chęcią zapisu i posiada indywidualny numer Ciąg zdarzeń: 1. Student otwiera swoją pustą kartę zapisów 2. Dla każdego wymaganego kursu z katalogu 1. System sprawdza dostępność miejsc i podaje możliwe do zapisu grupy zajęć 2. Student wybiera odpowiadającą mu grupę zajęć 3. System dodaje studenta do tej grupy i do jego karty zapisów z komunikatem zapisany. Koniec powtórzenia (punkt 2: pętla dla każdego ). 3. System zapisuje harmonogram zajęć studenta. Warunki końcowe: student zapisany na wymaganą listę kursów GHJ-PWR 23

24 SCENARIUSZ ALTERNATYWNY PU: ZAPIS NA WYMAGANE KURSY Warunki wstępne: Student z chęcią zapisu i posiada indywidualny numer Ciąg zdarzeń: 1. Student otwiera swoją pustą kartę zapisów. 2. Dla każdego wymaganego kursu z katalogu 1. System sprawdza, czy student spełnia warunki wstępne do zapisu na ten kurs a) Jeżeli student spełnia warunki wstępne, system sprawdza dostępność miejsc i podaje możliwe do zapisu grupy zajęć. 1. Student wybiera odpowiadającą mu grupę zajęć. 2. System dodaje studenta do tej grupy i do jego karty zapisów z komunikatem zapisany. b) Jeżeli student nie spełnia warunków wstępnych, system podaje komunikat: 1. kontynuacja wyboru grupy dla kolejnego kursu 2. anulowanie całej operacji. Jeżeli student wybierze punkt 2.1.b.1, to system wraca do punktu 2.1. Jeżeli student wybierze punkt 2.1.b.2 to przypadek użycia się kończy. Koniec powtórzenia (punkt 2: pętla dla każdego ). 3. System zapisuje harmonogram zajęć studenta. Warunki końcowe: student zapisany na kurs albo zapis anulowany. GHJ-PWR 24

25 WYSZUKIWANIE NADZWYCZAJNYCH CIĄGÓW ZDARZEŃ [5, S. 46] Przeglądanie scenariusza optymistycznego i zadawanie pytań: Czy jest jakaś inna czynność, którą można wykonać w tej chwili? Czy coś może się w tej chwili nie udać? Czy jest jakieś zachowanie, które może wystąpić w dowolnej chwili? Użycie kategorii do wykrywania wariantów Aktor kończy działanie programu. Aktor anuluje daną operację. Aktor uruchamia program pomocy. Aktor wprowadza niepoprawne dane. Aktor wprowadza niekompletne dane. Aktor wybiera alternatywną metodę wykonania PU. System się zawiesza. System jest niedostępny. GHJ-PWR 25

26 INNE TECHNIKI PISANIA SCENARIUSZY Podejście zwinne, ang. Agile Podejście sterowanie zachowaniem, ang. BDD - Behavior Driven Development GHJ-PWR 26

27 SCENARIUSZ JAKO OPOWIADANIE UŻYTKOWNIKA (USER STORY) AGILE [2] Szablon pisania narracji użytkownika: gdzie: Ja, jako <rodzaj użytkownika>, chcę <cel> żeby <przyczyna> rodzaj użytkownika osoba (rola), która oczekuje, spodziewa się korzyści z produktu, cel oczekiwana cecha, właściwość produktu (funkcja), przyczyna korzyść lub wartość właściwości L.p. Opowiadanie (user story) 1 Jako kasjer, chcę ciągłego dostępu do rejestru sprzedaży, żeby szybko obsługiwać płatności klientów 2 Jako sprzedawca, chcę autoryzowanego dostępu do danych, żeby prowadzić zapisy sprzedaży 3 Jako bibliotekarz, chcę zamawiać książki z ofert wydawnictw, żeby nie wysyłać niekompletnych albo błędnych zamówień GHJ-PWR 27

28 SZABLON SCENARIUSZA BDD [3, S. 157] Zakładając <kontekst> (1) warunki wstępne i/lub dane wejściowe tzw. ustawienie sceny Gdy <coś się wydarzy> (2) sprawdzane działanie Wtedy <oczekujemy jakiegoś wyniku> (3) oczekiwany wynik Uzupełniające szablon słowa kluczowe: I, Ale GHJ-PWR 28

29 SCENARIUSZ BDD JAKO NARRACJA I ZBIÓR PRZYKŁADÓW [3, S. 199] Scenariusz: zdobywanie dodatkowych punktów za loty w programie FF według statusu uczestnika Zakładając jestem uczestnikiem programu FF o statusie <status> Gdy podróżuję lotem, który jest wart <punkty bazowe> punktów Wtedy powinienem zdobyć premię wynoszącą <premia> punktów I powinienem korzystać z gwarantowanego minimum zdobytych punktów za podróż w liczbie <minimum> punktów I powinienem zdobyć całkowitą liczbę <razem> punktów Przykłady: Status Punkty bazowe Premia Minimum Razem Uwagi standard srebrny min punktów złoty % premii GHJ-PWR 29