Przypadek użycia
Transkrypt
Przypadek użycia
Model przypadków użycia Anna Bobkowska ykładu w o d e z cnic TI PG. o E m o le p ia z ły d Materia ia na Wy n a w ładzie. o k y m w a r a g n o i r rii Op obecnośc elu oraz ich je u z Inżynie p ę t s a nie za innym c Ich lektur nie materiałów w nione. o r b a a t z s t y s z je Wykor chnianie e z s w o p roz slajd 1 Diagram przypadków użycia • Pokazuje: – funkcjonalność systemu widzianą od zewnątrz, zbiór usług • Identyfikowani są: – aktorzy, przypadki użycia oraz powiazania i związki między nimi Przypadek użycia 1 Aktor 2 Aktor 1 Przypadek użycia 2 • Określa: – granice systemu: – użytkowników i inne systemy współpracujące z systemem - aktorzy – funkcjonalność realizowana przez system: przypadki użycia Przypadek użycia 3 System Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia oraz nowych powiązań slajd 2 Definicje • Model przypadków użycia - funkcjonalność z punktu widzenia użytkownika, system widziany jako „czarna skrzynka”. • Przypadek użycia (ang. use case) - (spójna) jednostka funkcjonalności dostarczana przez system, która jest realizowana jako ciąg interakcji pomiędzy aktorem a systemem. • Aktor (ang. actor) - abstrakcyjny użytkownik systemu, reprezentujący grupę rzeczywistych użytkowników o podobnych funkcjach i sposobie komunikacji z systemem; najczęściej aktor jest sprawcą zdarzenia powodującego uruchomienie przypadku użycia. • Powiązanie Aktor - Przypadek użycia (ang. association) usługa określona przez przypadek użycia jest dostępna dla aktora, aktor i system komunikują się podczas realizacji przypadku użycia. • System lub obiekt (ang. Subject) posiada przypadki użycia slajd 3 Klasyfikacja aktorów • Aktor główny - korzysta z podstawowych funkcji systemu • Aktor drugorzędny - korzysta głównie z funkcji służących do realizacji zadań pomocniczych (np. administrowania i pielęgnacji systemu) • Aktor aktywny - inicjuje przypadek użycia • Aktor pasywny - nie inicjuje przypadku użycia, lecz tylko w nim uczestniczy • Aktor ożywiony – reprezentacja grupy ludzi • Aktor nieożywiony – system urządzenie • Aktor zewnętrzny – domyślnie • Aktor wewnętrzny – w modelowaniu biznesowym slajd 4 Identyfikacja aktorów • • • • Kto komunikuje się z systemem ? Kto będzie korzystał z funkcji systemu ? Kto będzie system pielęgnował ? Jakie urządzenia system obsługuje ? (aktorzy nieożywieni) • Z jakimi innymi systemami system się komunikuje? (aktorzy będący innymi systemami) • Kto lub co jest zainteresowane wynikami pracy systemu ? slajd 5 Identyfikacja przypadków użycia • Dla każdego aktora odpowiedz na pytania: – jakiej funkcji aktor wymaga od systemu: czy aktor musi pamiętać, tworzyć, usuwać, modyfikować informacje w systemie – czy aktor ma być powiadamiany o zdarzeniach w systemie, i na odwrót • Rozważ, jakie są wejścia i wyjścia systemu • Staraj się powiązać w jeden przypadek użycia zespół funkcji wspólnie realizujących ten sam cel • Opisz przypadki użycia w języku naturalnym, według określonego szablonu • Zobrazuj aktorów i przypadki użycia na diagramie przypadków użycia • Przeanalizuj powiązania pomiędzy aktorami, pomiędzy przypadkami użyciaoraz pomiędzy aktorami i przypadkami użycia slajd 6 Przypadki użycia biznesowe i programowe ‘BIZNESOWE’ • Cel: pokazanie roli i usług dostarczanych przez organizację • Granica: Usługi wykonywane przez ludzi mogą być wewnątrz systemu • Aktorzy wewnętrzni – użytkownicy systemu w danej organizacji ‘PROGRAMOWE’, „funkcjonalne” • Cel: pokazanie wymagań względem systemu • Granica: Wewnątrz systemu tylko funkcjonalność oprogramowania (ewent. obsługiwanych urządzeń) Rezerwacja Z a m e ld o w a n ie Recepcjonistka Rejest racja zameldowania <<include>> G ość W y m e ld o w a n ie Rejestracja wymeldowania R e c e p c jo n is ta Płacenie <<include>> Sprzątaczka Pobieranie nr pokoju do sprz ątniecia Zaznaczenie do sprzątnięcia S p rz ą tn ię c ie p o k o ju Rejestracja s przątnięcia slajd 7 P o k o jo w a Przykład: Hotel Opis problemu Hotel Hilton przyjmuje gości. Recepcjonista rejestruje i wymeldowuje gości oraz pobiera opłatę. W hotelu jest wiele pokoi; sprzątają je pokojowe. Pokój może być wynajęty bezpośrednio przy przyjeździe gościa, jeżeli istnieją wolne pokoje. Gość płaci recepcjoniście przed wymeldowaniem. Pokój może być posprzątany dopiero po zwolnieniu. Pokój musi być sprzątnięty przed wynajęciem kolejnemu gościowi. slajd 8 Diagram przypadków użycia (biznesowy) Zameldowanie Gość Wymeldowanie Recepcjonista Sprzątnięcie pokoju Pokojowa slajd 9 Opis tekstowy przypadków użycia • Przypadek użycia: Zameldowanie OPIS TEKSTOWY Sposób postępowania podczas zameldowania gościa do pokoju PROCEDURA S1: Gość wchodzi do hotelu. S2: System sprawdza, czy Gość zarezerwował pokój. S3: Jeśli TAK, wtedy przejdź do S4. Jeśli NIE, system sprawdza, czy są wolne pokoje. Jeśli TAK, pokój jest rezerwowany dla Gościa; przejdź do S4. Jeśli NIE, przypadek jest kończony z komunikatem: BRAK MIEJSC. S4: Pokój jest przydzielony Gościowi. Do Recepcjonisty jest wysyłany komunikat PODAJ KLUCZ I KARTĘ. Gość otrzymuje klucz i kartę gościa. slajd 10 Opis tekstowy przypadków użycia • Przypadek użycia: Wymeldowanie S1: Gość przybywa do recepcji z zamiarem opuszczenia hotelu. S2: System oblicza rachunek. Gość płaci. S3: Recepcjonista wysyła komunikat do Pokojowej, aby sprzątnęła zwalniany pokój. S4: Do Recepcjonisty system wysyła komunikat ODBIERZ KLUCZ. Gość zwraca klucz i kartę gościa. • Przypadek użycia: Sprzątnięcie pokoju S1: Pokojowa otrzymuje komunikat od Recepcjonisty o konieczności sprzątnięcia podanego pokoju. S2: Pokojowa sprząta pokój. S3: Pokojowa wysyła komunikat do Recepcjonsty o sprzątnięciu pokoju. slajd 11 Związki między przypadkami użycia • Zawiera (include) - w starszych wersjach używa (uses) – związek „A include B” oznacza, że w czasie wykonywania przypadku użycia A jest wykonywana także funkcjonalność zdefiniowana przez B • Rozszerza (extend) – „przypadek użycia C rozszerza przypadek użycia D”, gdy opcjonalnie (w określonych warunkach) do D zostaje włączone wykoanie funkcjonalności C , np. C uzwględnia nową sytuację wyjątkową nie obsługiwaną przez D. Rejestracja samochodu «include» Przegląd samochodu • Uogólnienie slajd 12 «extend» Mycie samochodu (Aktor-Aktor) (Przypadek użycia-Przypadek użycia) Opis warunków na związku ze stereotypem <<extend>> Punkt rozszerzeń (ang. extensionPoint) – miejsce w którym może nastąpić Rozszerzenie wyspecyfikowane przez związek <<extend>> slajd 13 Krotności cji a k i f y pec s ć ś wo Możli otności na kr aniu z ą i w po iem k d a p przy z a r a akto użyci slajd 14 Hotel – model funkcjonalny Rezerwacja Recepcjonistka Rejest racja zameldowania <<include>> Rejestracja wymeldowania Płacenie <<include>> Sprzątaczka Pobieranie nr pokoju do sprz ątniecia Zaznaczenie do sprzątnięcia Rejestracja s przątnięcia slajd 15 Opis przypadku użycia • Opis nieformalny • Opis ustrukturalizowany • Interakcje pomiędzy aktorami a systemem lub pomiędzy obiektami w systemie na diagramach opisujących dynamikę systemu Cechy opisu: • Powinien opisywać użyteczną funkcjonalność systemu. • Powinien określać, jak i kiedy przypadek się zaczyna i kończy. • Powinien zawierać opis interakcji przypadku użycia z aktorami (przepływ zdarzeń, uczestniczące obiekty). • Powinien składać się z przebiegu podstawowego oraz przebiegów alternatywnych (wyjątkowych). • Powinien uwzględniać związki pomiędzy przypadkami użycia. slajd 16 Ustrukturalizowany opis przypadku użycia Wzorzec opisu slajd 17 Nazwa przypadku Nazwy obiektów Aktorzy Streszczenie Nazwa przypadku użycia Nazwy obiektów, których dotyczy przypadek użycia Obiekty inicjujące/biorące udział w przypadku Skrótowy opis najważniejszych zachowań modelowanych przez przypadek użycia Zdarzenie inicjujące Zdarzenie rozpoczynające sekwencję interakcji Struktura Opis struktury przypadku użycia Warunki początkowe Warunki umożliwiające wystąpienie danego przypadku użycia Pełny opis Opis interakcji pomiędzy obiektami, z wyszczególnieniem miejsc, w których mogą wystąpić sytuacje wyjątkowe Sytuacje wyjątkowe Opis nietypowych sytuacji (przebiegów) mogących wystąpić w ramach przypadku użycia Warunki końcowe Stan, w jakim przypadek użycia pozostawia uczestniczące w nim obiekty Komentarz Dodatkowe informacje nie związane z funkcjonalnością danego przypadku użycia, przydatne w dalszych etapach modelowania Ustrukturalizowany opis przypadku użycia Przykład opisu Nazwa przypadku Wymeldowanie Nazwa obiektu System hotelowy Aktorzy Gość, Recepcjonista Streszczenie Procedura realizowana przy opuszczaniu hotelu przez gościa Zdarzenie inicjujące Zgłoszenie wyjazdu przez Gościa Struktura Brak Warunki początkowe Brak Pełny opis Gość zgłasza wyjazd, płaci i zwraca klucze od pokoju (wyjątek: zgubione klucze). Recepcjonista sprawdza zapłacenie rachunku (wyjątek: nie zapłacono) i wydaje Pokojowej polecenie sprzątnięcia pokoju. Sytuacje wyjątkowe Zgubiono klucze: żądanie zapłacenia przez Gościa kosztu kluczy. Nie zapłacono: żądanie zapłacenia rachunku przez Gościa. slajd 18 Warunki końcowe Pobyt opłacony, klucz zwrócony, zainicjowane sprzątanie pokoju. Komentarz Sprzątanie pokoju jest osobnym przypadkiem użycia. Obsługa sytuacji Zgubiono klucze oraz obsługa płacenia mogą być modelowane osobnymi przypadkami użycia. Use Case Model in Context Functional requirements specification User interface design slajd 19 Use case model System design Configuration of the system Test design Przypadki użycia w cyklu wytwarzania oprogramowania • Specyfikacja wymagań funkcjonalnych na system • Weryfikacja poprawności i kompletności specyfikacji wymagań • Wspomaganie walidacji wymagań • Punkt wyjścia do opracowania testów (w tym akceptacyjnych) systemu • Identyfikacja składowych (obiektów) systemu • Podstawa do opracowania diagramów interakcji (scenariuszy) • Możliwość śledzenia, jak wymagania przeradzają się w klasy obiektów i operacje systemu • Podstawa do oceny rezultatów testów slajd 20 Zalety modelowania przypadkami użycia • Określenie granic systemu i aktorów zewnętrznych • Funkcjonalność systemu wyrażona w terminach istotnych dla aktorów zewnętrznych • Określenie logiki realizacji funkcjonalności w systemie • Zrozumiałość i komunikatywność • Przydatność w różnych fazach cyklu wytwarzania oprogramowania • Przydatność dla celów prezentacji i dokumentacji slajd 21 Biblioteka – model biznesowy Wypożyczenie książki Bibliotekarz Czyt elnik Zwrot książki Korzystanie z książki w czytelni slajd 22 Biblioteka – poglądowy model programowy Przeglądanie katalogu Zamawianie książki W ydawanie książek Czytelnik Zwrot ksi ążek Sprawdzanie konta <<extend>> odnotownie opłaty za przetrzymywanie Bi bliot ekarz W ysyłanie upomnień Dodawanie/usuwanie ksi ążek Zarządzanie kontami czytelników slajd 23