Plan wykładu 2. Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja

Transkrypt

1 Plan wykładu 2 Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja 1

2 Model Przypadków Użycia Reprezentuje użytkowanie systemu. Stosuje sie do systemu biznesowego i/lub informatycznego. Aktor: spójny zbiór ról użytkującego system (rola: zachowanie bytu w pewnym kontekście): może reprezentować osobę lub inny system, jest poza systemem i poza kontrolą systemu, ma nazwę i krótki opis. Przypadek Użycia (PU) systemu: proces interakcji jednego lub wielu aktorów z systemem (być może wielowariantowy): jest inicjowany przez aktora (z reguły); polega na wykonywaniu czynności przez aktorów i system w zadanej kolejności, zmierza do dostarczenia aktorowi godnego uwagi wyniku (osiągnięcia celu aktora), ma nazwę i opis (mniej lub bardziej szczegółowy). 11

3 Diagram PU - graficzna reprezentacja modelu PU - elipsa z nazwą PU wewnątrz lub obok. Nazwa PU1 Aktor - "ludzik" z nazwą aktora. Nazwa aktora1 Nazwa aktora1 Nazwa PU2 System Nazwa PU1 Nazwa PU2 Nazwa aktora2 Linie lub strzałki łączące symbole przypadków użycia i aktorów reprezentują ich powiązanie (komunikację). Strzałka pokazuje kierunek inicjowania (np. od aktora do PU oznacza, że dany aktor inicjuje dany PU). System może być zaznaczony jako prostokąt (opcjonalnie). 12

4 Diagram PU może być: ogólnym przeglądowym diagramem przedstawiającym wszystkich aktorów i wszystkie PU; ogólnym diagramem aktorów, przedstawiającym związki między aktorami; diagramem przeglądowym aktora pokazującym wszystkie powiązania tego aktora z PU; ogólnym diagramem PU pokazującym zgrupowania logicznie powiązanych przypadków użycia i aktorów; diagramem przeglądowym PU pokazującym wszystkie powiązania tego PU z aktorami i innymi PU. 13

5 Dwa rodzaje modeli PU Model biznesowych PU Biznesowe PU - to procesy organizacji Cel budowania modelu: zrozumieć organizacje, znaleźć aktorów i PU SI, odkryć ważne pojęcia, dokumenty Klasy Model PU systemu inform. 14

6 Model biznesowych Przypadków Użycia Cel: przedstawić otoczenie i jego związki z procesami organizacji. Aktor: ktoś lub coś na zewnątrz organizacji, ale biorący udział w jej działalności lub zainteresowany jej wynikami. Przykłady: Klient, Dostawca, System sprawdzania kart płatniczych, inny dział firmy. Przypadek Użycia (biznesowy) = proces organizacji: zbiór ciągów akcji dostarczający obserwowalny wynik. Model PU odwzorowuje gospodarczą działalność organizacji na bardzo wysokim poziomie abstrakcji (bez szczegółów realizacji). Model PU dla organizacji pozwala określić granicę środowiska SI! 15

7 : Student Dzi e ka n a t za rzą d za n i e re j e stra cj ą Zł o że n i e i n d e ksu S p ra wd ze n i e sta tu su Odebra n i e i n d e ksu P rze p ro wa d ze n i e re j e stra cj i n a se m e str : Czas : System rekrutacyj ny Wykorzystane źródło: Śmiałek M. Zrozumieć UML2.0 Metody modelowania obiektowego HELION,

8 Biuro T urystyczne Klient Świadcz usługę tu rystyczn ą Pozyskuj obiekt turystyczny Dysponent Przyjm ij rezygnację Rozwiąż um owę Termin wydania katalogu Firma Osoba Wydaj katal og 17

9 Poziom szczegółowości modelu PU Modelowanie PU jest procesem iteracyjnym i polega na kolejnym uściśleniu (a niekiedy i znalezieniu nowych) aktorów i PU. Nie każdy PU musi być szczegółowo opisany. Niektóre PU wystarczy tylko nazwać lub opisać deklaratywnie, przedstawić prototyp interfejsu użytkownika itp. 19

10 Przykład opisu PU (biznesowego) PU 4 Negocjacja oferty Ubezpieczenia Grupowego Klient po przedstawieniu oferty stworzonej przez Koordynatora ds. Sprzedaży Ubezpieczeń Grupowych ma możliwość ewentualnej zmiany warunków zapytania ofertowego oraz negocjowania ostatecznej formy ubezpieczenia. Analizując wymagania klienta towarzystwo ma możliwość ustalenia konsensusu oraz stworzenia ostatecznej oferty na warunkach niestandardowych. 20

11 Opis (specyfikacja) PU Opis przypadku użycia jest opisem interakcji systemu i aktorów, która polega na kolejnym podejmowaniu akcji przez system i aktorów. Interakcja ma więc pewien przebieg określony przez kolejność akcji. Zakłada się, że każdy przypadek użycia może mieć wiele różnych przebiegów, w zależności od sytuacji, jakie pojawiają się w trakcie interakcji aktorów z systemem. Spośród wielu przebiegów wybiera się jeden najbardziej typowy i nazywa się go podstawowym lub bazowym. Pozostałe przebiegi nazywa się alternatywnymi. Zamiast terminu przebieg stosuje się także termin scenariusz. 21

12 Opis (specyfikacja) PU c.d. W UML nie ustalono standardu na formę opisu PU, ale przyjęto opisywać na dwa sposoby: specyfikując wszystkie możliwe sytuacje, jakie mogą zajść w przebiegu PU, używając przy tym konstrukcji warunkowych i powtarzania; ten sposób nadaję się przy mało skomplikowanych PU; stosując tylko sekwencje opisuje się przebieg podstawowy oraz przebiegi alternatywne; każdy przebieg jest wtedy przedstawiany jako uporządkowana sekwencja akcji. 22

13 Rysunek symbolicznie przedstawia warianty realizacji PU przebieg podstawow y warunek wstępny przebieg alternatywn y warunek końcowy warunek końcowy warunek końcowy Warunek wstępny: stan otoczenia i/lub systemu, który warunkuje rozpoczęcie PU(musi istnieć mozliwość jego sprawdzenia przed rozpoczęciem PU) Warunek końcowy: poprawny stan systemu po zakończeniu PU.(niekiedy brzmienie jest zgodne z celem PU, może być wtedy opuszczony). Jeśli niektóre warunki wstępne i/lub końcowe muszą być spełnione we wszystkich PU, to umeszcza się wspólną odpowiednią odnotację. 23

14 Przykład 1. Opis PU z uwarunkowaniami ID: PU12 Aktorzy: Klient Przypadek użycia: Znajdź produkt. Warunek wstępny: klient jest zarejestrowany. Przebieg zdarzeń: 1.Klient wybiera "szukaj produkt" 2. System żada podania kryteriów wyszukania. 3. Klient podaje kryteria. 4. System wyszukuje produkty, spelniające kryteria. 5. Jeśli system znajduje produkty, to 5.1 Dla każdego znalezionego produktu System wyświetla krótki opis produktu System wyświetla zestaw składników produktu System wyświetla cenę produktu. 6. w przeciwnym przypadku 6.1 System informuje klienta o tym, że nie znaleziono odpowiednich produktów. Warunki końcowe: Przebieg alternatywny: 1. W dowolnym momencie Klient może przejść na inną stronę. 24

15 Opis złożonych PU Jeden przebieg wybiera się jako podstawowy. Przebieg - jedna wybrana ścieżka w drzewie możliwych realizacji PU. W przebiegu nie ma rozgałęzień. Każde rozgałęzienie rodzi inny przebieg alternatywny, opisywany osobno. Przypadek użycia: WypłataGotówki ID: oznaczeniepu11 Aktorzy: Warunek wstępny: Przypadek użycia: WypłataGotówki Przebieg alternatywny:nieważnyidentyfikatorklie nta ID: oznaczeniepu Przebieg zdarzeń: Warunki końcowe: Przebiegi alternatywne: 1. Nieważny Identyfikator Klienta. 2. Nieważna karta kredytowa. Aktorzy: Warunek wstępny: Przebieg zdarzeń: 1. PU zaczyna się w kroku... PU11, kiedy... 25

16 SuperBankomat. Model przypadków użycia ID PU3 Nazwa: Wypłata gotówki Cel: Wypłata gotówki klientowi na podstawie karty płatniczej. Aktorzy: Klient, System CKP. Warunek wstepny: Ekran prezentuje menu główne. Przebieg podstawowy: 1.PU rozpoczyna klient wkładając kartę płatniczą. Następuje realizacja PU2 Identyfikacja tożsamości klienta (include). 2.Bankomat proponuje wybór opcji. 3.Klient wybiera opcję Wypłata gotówki. 4.Bankomat pyta o kwotę. Zazwyczaj jest lista kwot do wyboru ( 'hot-keys'). Kwota może również być wprowadzona z klawiatury. 5. Bankomat wysyła Identyfikator karty, kwotę, datę, godzinę i numer rachunku do Systemu CKP jako transakcję System CKP odpowiada poleceniem "wykonaj". 6. Bankomat wydaje pieniądze. 7. Bankomat zwraca kartę. 8. Bankomat drukuje pokwitowanie. Przebiegi alternatywne: A1. Brak gotówki w bankomacie. Jeżeli w bankomacie zabrakło pieniędzy, pobranie gotówki jest niemożliwe; alternatywny ciąg następuje po kroku 4 w głównym przebiegu. [Powinno pojawić się ostrzeżenie na ekranie informujące o braku pieniędzy. Ostrzeżenie powinno być dostrzegalne przez klienta jeszcze zanim włoży on kartę. A2.Niewłaściwa kwota. Następuje w kroku 4 przebiegu podstawowego, jeżeli klient wybierze kwotę, która nie może zostać wypłacona banknotami znajdującymi się w bankomacie; wówczas system wyświetli ostrzeżenie i poprosi klienta o zmianę kwoty. Sytuacja może się powtarzać aż do momentu wprowadzenia właściwej kwoty (zazwyczaj jest to wielokrotność liczby 20). 26

17 Uogólnienie między aktorami Uogólnienie (generalizacja) między aktorami - związek między aktorem bardziej ogólnym (rodzicem) a aktorem bardziej wyspecjalizowanym (dzieckiem). Dziecko dziedziczy role ( a więc i powiązania z PU) rodzica. 17

18 Strukturalizacja Przypadków Użycia (poszukiwanie i wydzielenie pewnych struktur fragmentów PU) Są trzy główne powody strukturalizacji PU: ułatwienie zrozumienia; ułatwienie wielokrotnego użycia specyfikacji PU; ułatwienie utrzymania modelu. Kiedy należy zająć się strukturalizacją PU? Najlepiej zrobić to po szczegółowym opisaniu możliwych przebiegów PU i ich zrozumieniu. W strukturalizacji wykorzystuje się następujące rodzaje związków PU: zależności: zawierania rozszerzenia uogólnienia (generalizacji/specjalizacji). 18

19 Uogólnienie (generalizacja) między PU: dwa lub więcej PU są specjalizacjami abstrakcyjnego, ogólnego PU. Należy skorzystać z uogólnienia, jeśli prowadzi to do uproszczenia modelu, a nie do jego skomplikowania! PU-dziecko: dziedziczy wszystkie cechy rodzica (związki, warunki wstępne i końcowe, kroki podstawowego i alternatywnego przebiegu); może mieć dodane inne związki, warunki wstępne i końcowe, kroki podstawowego i alternatywnego przebiegu zdarzeń; może zamienić cechy odziedziczone własnymi specyficznymi (za wyjątkiem związków). 19

20 Jak opisywać na diagramie uogólnione PU? UML tego nie określa. Znajdź Produkt Znajdź Książkę Znajdź CD Styl opisu może być określony wewnętrznym standardem firmy lub zespołu twórców systemu. W przykładzie zastosowano zasadę: jeśli krok zmieniono - został on wyróźniony poprzez napisanie kursywą; jeśli krok dodano: został on wyróźniony poprzez wytłuszczenie. 20

21 ID: PU11 Przypadek użycia: ZnajdźProdukt Aktorzy: Klient Warunek wstępny: Przebieg zdarzeń: 1. Klient wybiera "Znajdź produkt" 2. System pyta o kryteria wyszukiwania. 3. Klient wprowadza kryteria. 4. System wyszukuje produkty. 5. Jeśli system znajduje, to 5.1 System wyświetla listę produktów 6. W przeciwnym przypadku 6.1 System komunikuje, że nie znaleziono. Przypadek użycia: ZnajdźKsiążkę ID: PU67 ISA PU11 Aktorzy: Klient Warunek wstępny: Przebieg zdarzeń: 1.Klient wybiera "Znajdź książkę" 2.System pyta o kryteria wyszukiwania książki: autora, tytul, ISBN lub temat. 3. Klient wprowadza kryteria. 4. System wyszukuje książki. 5. Jeśli system znajduje, to 5.1 System wyświetla listę produktów 6. W przeciwnym przypadku 6.1 System komunikuje, że nie znaleziono. Warunki końcowe: Warunki końcowe: Alternatywne przebiegi: 21

22 Zależność <<zawiera>> ( ang. <<include>>) między PU Jeśli w PU jest taki fragment przebiegu, że: do zrozumienia PU nie są istotne szczegóły przebiegu tego fragmentu, ważny jest jego wynik, nie sposób realizacji, lub jeśli stanowi on wspólny fragment wielu przypadków użycia, można ten fragment wyodrębnić w osobny podprzypadek użycia. Wyodrębniona część jawnie jest częścią PU, zawiera się w nim. Używamy w tym przypadku związku zależności <<include>>. Zależność <<include>> oznacza, że operacje "zawieranego" podprzypadku użycia (strzałka na niego wskazuje) są realizowane zawsze w przypadku zawierającym. Notacja: przerywana linia ze strzałką i tekstem <<include>> (lub spolszczonym <<zawiera>>). 22

23 Zależność zawierania się między PU na diagramie i w opisach: Zamów Produkt <<include>> Znajdź Produkt Przypadek użycia: ZamówProdukt Przypadek użycia: ZnadźProdukt ID: oznaczeniepu11 Aktorzy: Branżysta Warunek wstępny: zalogowany w systemie Przebieg zdarzeń: include (ZnajdźProdukt) 3 ID: oznaczeniepu16 Aktorzy: Branżysta Warunek wstępny: Przebieg zdarzeń:

24 Związek zależności <<rozszerza>> ( ang. <<extend>>) między PU Jeśli fragment PU jest opcjonalny i nie jest konieczny do zrozumienia głównego celu PU, można ten fragment wydzielić w osobny podpu i uprościć tym samym strukturę podstawowego. W tym przypadku używamy związku <<extend>>. Podstawowy PU "nic nie wie" o możliwym jego rozszerzeniu. Rozszerzający podpu musi się "powołać" na miejsce w podstawowym PU na tzw. punkt rozszerzenia. Miejsce to jest oznaczone, ale nie ponumerowane, jest między ponumierowanymi krokami! 24

25 Zależność rozszerzania między PU na diagramie i w opisach: Zwrot Ksiązki punkt rozszerzenia przeterminowany <<extend>> (przeterminowany) Ukaranie grzywną Przypadek użycia: ZwrotKsiążki ID: PU11 Aktorzy: Bibliotekarz Warunek wstępny: Przebieg zdarzeń: 1. Bibliotekarz wprowadza ID Czytelnika. 2. System wyświetla listę wypożyczonych książek. 3. Bibliotekarz wskazuje książkę zwracaną. <ukaranie grzywną> 4. Bibliotekarz rejestruje zwrot.... Rozszerzający PU: UkaranieGrzywną ID: PU16 Dołączany segment 1: Jeżeli książka przeterminowana: 1. Bibliotekarz wybiera rejestracje zapłaty grzywny. 2. System wyświetla formularz. 3. Bibliotekarz rejestruje opłatę grzywny

26 Strukturalizacja PU PU-1 Przyjmij zamówienie Aktorzy Sprzedawca Warunek wstępny: Podstawowy przebieg zdarzeń: 1. PU rozpoczyna Sprzedawca wybierając odpowiednią opcję. 2. System prezentuje formularz zamówienia. 3. Sprzedawca podaje dane pozwalające zidentyfikować klienta (PESEL lub Nazwisko/Nazwę firmy). 4. System wypełnia formularz zamówienia danymi klienta. 5. Sprzedawca wprowadza pozycje zamówienia. W tym celu dla każdej zamawianej pozycji: 5.1 podaje symbol (z indeksu) lub nazwę produktu. 5.2 system wyszukuje produkt i podaje jego stan; 5.3 sprzedawca potwierdza wybór i podaje ilość; 5.4 system prezentuje wypełnioną pozycję i umożliwia przejście do następnej lub zakończenie. 6. Sprzedawca potwierdza zamówienie. 7. System zapamiętuje zamówienie, rezerwuje zamówione produkty i wraca do poprzedniej opcji. Warunek końcowy: Zamówienie zarejestrowano, produkty zarezerwowano. Alternatywne przebiegi. A1. Nowy klient:ma miejsce po kroku 3, kiedy klient jest obsługiwany po raz pierwszy. 1. Sprzedawca wywołuje opcje Nowy klient.... <<zawiera się>> /<<include>> PU-2 Wyszukaj produkt Aktorzy Warunek wstępny: Przebieg zdarzeń: Po wybraniu odpowiedniej opcji system umożliwia podanie nazwy i/lub indeksu produktu, następnie sprawdza stan magazynu i prezentuje wynik. <<rozszerza>> /<<extend>> PU-3 Zarejestruj klienta rozszerzający PU-1 w pkt. Nowy klient Aktorzy Warunek wstępny: Podstawowy przebieg zdarzeń: 1. PU rozpoczyna się wybraniem odpowiedniej opcji po kroku 3 PU-1, jeśli klient po raz pierwszy składa zamówienie. 2. System prezentuje formularz klienta. 3. Aktor podaje nazwisko klienta, PESEL, adres dostarczania zamówionych produktów,

27 ud Gospodarownie nieruchomościami mieszkania Przeprowadź Dokonaj zakupu Dokonaj Petent Dokonaj zakupu komunalnego gruntu komunlanego wydzierżawienia nieruchomosci Zmień zasady wydzierżawienia nieruchomości sesję rady gminy Uzyskaj dodatek mieszkaniowy Ustal granice podziału dla nieruchomości «exte n d» Rada gminy

28 Pytania kontrolne 1. Czy aktor to zawsze osoba? 2. Jaki związek łączy aktora a PU? 3. Czy wiele osób fizycznych może reprezentować jeden aktor? 4. Czy jedna osoba fizyczna może być w roli wielu aktorów? 5. Czy ten sam aktor może wystąpić na wielu diagramach? 6. Czy z jednym aktorem może być związanych wiele PU? 7. Czy z jednym PU może być związanych wielu aktorów? Jeśli tak, to co to oznacza? 8. Kiedy jest wykorzystywany związek uogolnenia miedzy aktorami? 9. Na jakim etapie prac nad modelem PU przeprowadza się strukturalizację? 10. W "podpu" zawierane wydziela się fragmenty podstawowych przebiegów, czy alternatywnych? 11. W "podpu" rozszerzające wydziela się fragmenty podstawowych przebiegów, czy alternatywnych? 29