1 / 31

UML

UML. Unified Modeling Language Wykład 4 Przypadki użycia. Use Case Diagram. Diagram przypadków użycia to przedstawienie użytkowników systemu (aktorów), funkcji wykonywanych przez system (przypadków użycia) i związków między nimi.

hagen
Download Presentation

UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. UML Unified Modeling Language Wykład 4 Przypadki użycia

  2. Use Case Diagram Diagram przypadków użycia to przedstawienie użytkowników systemu (aktorów), funkcji wykonywanych przez system (przypadków użycia) i związków między nimi. Diagram PU ma ogromne znaczenie i jest początkiem modelowania. WSM dr Marek Szepski

  3. Cocburn:Jak pisać efektywne przypadki użycia, WNT IO • Schneider, Winters: Stosowanie przypadków użycia, WNT IO WSM dr Marek Szepski

  4. Elementy diagramu PU • System – to co mamy zrobić (granice) • Aktor – spójny zbiór ról odgrywanych przez użytkowników PU w czasie interakcji z tym PU • PU – to opisany ciąg akcji i ich wariantów, które system musi wykonać • Związek Aktor - PU WSM dr Marek Szepski

  5. Aktor To spójny zbiórról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym systemem. Aktor ma zachowanie (czyli może wykonać instrukcję: jeżeli). Aktor osobowy – nieosobowy (inny system komp. urządzenie, czas) Jeden aktor – wiele osób. Jedna osoba – wiele ról. WSM dr Marek Szepski

  6. Aktor GŁÓWNY: Uczestnik, który prosi system o realizację własnego celu. Zwykle rozpoczyna interakcję z systemem. Może działać przez pośrednika. Aktor POMOCNICZY (drugorzędny): Uczestnik, względem którego analizowany system macel. Sam nie inicjuje interakcji, ale wymienia komunikaty z systemem (np.. drukarka, istniejąca baza danych). UCZESTNIK poza systemem: ma interesy ochraniane przez system. WSM dr Marek Szepski

  7. Aktor: to informacja o jego profilu: typ, przeszłość, pozycja, umiejętności, doświadczenie, szkolenia itp... Aktorzy na diagramie PU to jedynie ich lista. Definicja aktora znajduje się w specyfikacji. Aktor jest zawsze poza systemem. WSM dr Marek Szepski

  8. Gdzie szukać aktorów • Kto korzysta z systemu? • Kto instaluje system? • Kto uruchamia system? • Kto pielęgnuje system? • Jakie inne systemy korzystają z tego s.? • Kto pobiera informacje? • Kto dostarcza informacje? • Czy coś dzieje się automatycznie? Aktor ma interes w stos. do systemu ! Lista: AKTOR -> CEL WSM dr Marek Szepski

  9. WSM dr Marek Szepski

  10. Diagram kontekstowy • Identyfikuje aktorów • Definiuje aktorów • Określa (częściowo) granice systemu WSM dr Marek Szepski

  11. PU Def:Przypadek użycia to specyfikacja ciągu akcji ich wariantów, które system może wykonać poprzez interakcje z aktorami tego systemu WSM dr Marek Szepski

  12. Przypadek użycia: • To opis działania systemu • To umowa na zachowanie systemu • To czynności, które aktor chce by system wykonał • Jest zawsze uruchamiany przez aktora • To zakres funkcjonalny usług systemu WSM dr Marek Szepski

  13. Opis PU WSM dr Marek Szepski

  14. Opis nieformalny • W małym dobrze współpracującym zespole • Np..: Gdy przedstawiciel handlowy otrzymuje prośbę o anulowanie zamówienia, wyszukuje zamówienie w systemie i zaznacza je jako anulowane. Następnie do systemu księgowego wysyłane jest zlecenie zwrotu pieniędzy na konto klienta. WSM dr Marek Szepski

  15. Opis formalny PU • Numer i nazwa • Opis – definicja • Twórca opisu • Aktorzy: główny, drugorzędny • Warunki wstępne • Główny scenariusz zdarzeń • Alternatywne scenariusze • Specjalne wymagania • Warunki końcowe • Uwagi WSM dr Marek Szepski

  16. PU - CRUD C – create R – read U – update D – delete Można połączyć w jednym opisie WSM dr Marek Szepski

  17. Obrazowanie PU • Diagram czynności (koncentracja na czynnościach) • Diagramy interakcji (koncentracja na komunikatach) - diagram sekwencji • Diagram maszyny stanowej (koncentracja na zmianie stanu obiektów) WSM dr Marek Szepski

  18. Jak pisać PU • Forma czynna zdania • Pisz z punktu widzenia wykonującego aktor robi, system robi, obiekt robi • Właściwa szczegółowość opisu • Z opisu coś wynika (błąd: system sprawdza – lepiej system potwierdza WSM dr Marek Szepski

  19. Przykład • Uczestnik aukcji wskazuje aukcję w której chce uczestniczyć • System wyświetla formularz do wpisania oferty • Uczestnik wpisuje ofertę a następnie wybiera licytuj • System rejestruje ofertę i informuje o tym uczestnika • Jeżeli aukcja w systemie holenderskim to następuje rozszerzenie: Finalizuj transakcje. 4a. Jeśli w kroku 3 uczestnik wpisał kwotę niezgodna z regulaminem, system informuje o tym i przechodzi do kroku 2 4b. Jeśli z powodu awarii technicznej lub zakończenia aukcji system nie może zarejestrować ofert, informuje o tym i następuje zakończenie PU WSM dr Marek Szepski

  20. System • Granice systemu: aktorzy i PULISTA: W – POZA • Podsystem, nadsystem: system informatyczny jest zwykle częścią systemu biznesowego i współpracuje z innymi lub nadrzędnymi systemami informatycznymi • Problem: to może się nam przydać,czy musimy to mieć? – trudne decyzje WSM dr Marek Szepski

  21. Związki • Asocjacja (może mieć kierunek) • Zawieranie <<include>> • Rozszerzenie <<extend>> • Uogólnienie (dziedziczenie) • Realizacja <<realise>> WSM dr Marek Szepski

  22. WSM dr Marek Szepski

  23. WSM dr Marek Szepski

  24. WSM dr Marek Szepski

  25. WSM dr Marek Szepski

  26. Intrfejs: z opisu PU wprost wynika specyfikacja interfejsów (nie twórz grafiki) • Testy: PU są gotowym planem testów systemu • DFD: aktor – terminatorPU – proceszwiązek – przepływ (różnice)? – skład danych WSM dr Marek Szepski

  27. WSM dr Marek Szepski

  28. WSM dr Marek Szepski

  29. WSM dr Marek Szepski

  30. Diagram Przypadków Użycia WSM dr Marek Szepski

  31. Perspektywa PU – zachowanie systemu Perspektywa projektowa – klasy, interfejsy, kooperacje Perspektywa procesowa – wątki, procesy, współbieżność, synchronizacja Perspektywa implementacyjna – komponenty i pliki Perspektywa wdrożeniowa - węzły WSM dr Marek Szepski

More Related