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

UML

  • Upload
    hagen

  • View
    36

  • Download
    0

Embed Size (px)

DESCRIPTION

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. - PowerPoint PPT Presentation

Citation preview

Page 1: UML

UML

Unified Modeling Language

Wykład 4Przypadki użycia

Page 2: UML

WSM dr Marek Szepski 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.

Page 3: UML

WSM dr Marek Szepski 3

Cocburn: Jak pisać efektywne

przypadki użycia, WNT IO Schneider, Winters: Stosowanie

przypadków użycia, WNT IO

Page 4: UML

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

Page 5: UML

WSM dr Marek Szepski 5

Aktor

To spójny zbiór ró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.

Page 6: UML

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 ma cel. Sam nie inicjuje interakcji, ale wymienia komunikaty z systemem (np.. drukarka, istniejąca baza danych).

UCZESTNIK poza systemem: ma interesy ochraniane przez system.

Page 7: UML

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.

Page 8: UML

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

Page 9: UML

WSM dr Marek Szepski 9

Page 10: UML

WSM dr Marek Szepski 10

Diagram kontekstowy Identyfikuje aktorówDefiniuje aktorówOkreśla (częściowo) granice systemu

Page 11: UML

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

Page 12: UML

WSM dr Marek Szepski 12

Przypadek użycia:To opis działania systemuTo umowa na zachowanie systemuTo czynności, które aktor chce by

system wykonałJest zawsze uruchamiany przez aktoraTo zakres funkcjonalny usług systemu

Page 13: UML

WSM dr Marek Szepski 13

Opis PU

Page 14: UML

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.

Page 15: UML

WSM dr Marek Szepski 15

Opis formalny PU1. Numer i nazwa2. Opis – definicja3. Twórca opisu4. Aktorzy: główny, drugorzędny5. Warunki wstępne6. Główny scenariusz zdarzeń7. Alternatywne scenariusze8. Specjalne wymagania9. Warunki końcowe10. Uwagi

Page 16: UML

WSM dr Marek Szepski 16

PU - CRUD

C – create

R – read

U – update

D – delete

Można połączyć w jednym opisie

Page 17: UML

WSM dr Marek Szepski 17

Obrazowanie PUDiagram czynności (koncentracja na

czynnościach)Diagramy interakcji (koncentracja na

komunikatach) - diagram sekwencji

Diagram maszyny stanowej (koncentracja na zmianie stanu obiektów)

Page 18: UML

WSM dr Marek Szepski 18

Jak pisać PU1. Forma czynna zdania

2. Pisz z punktu widzenia wykonującego aktor robi, system robi, obiekt robi

3. Właściwa szczegółowość opisu

4. Z opisu coś wynika (błąd: system sprawdza – lepiej system potwierdza

Page 19: UML

WSM dr Marek Szepski 19

Przykład1. Uczestnik aukcji wskazuje aukcję w której chce

uczestniczyć

2. System wyświetla formularz do wpisania oferty

3. Uczestnik wpisuje ofertę a następnie wybiera licytuj

4. System rejestruje ofertę i informuje o tym uczestnika

5. 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

Page 20: UML

WSM dr Marek Szepski 20

System Granice systemu: aktorzy i PU

LISTA: 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

Page 21: UML

WSM dr Marek Szepski 21

ZwiązkiAsocjacja (może mieć kierunek)Zawieranie <<include>>Rozszerzenie <<extend>>Uogólnienie (dziedziczenie)Realizacja <<realise>>

Page 22: UML

WSM dr Marek Szepski 22

Page 23: UML

WSM dr Marek Szepski 23

Page 24: UML

WSM dr Marek Szepski 24

Page 25: UML

WSM dr Marek Szepski 25

Page 26: UML

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

Page 27: UML

WSM dr Marek Szepski 27

Page 28: UML

WSM dr Marek Szepski 28

Page 29: UML

WSM dr Marek Szepski 29

Page 30: UML

WSM dr Marek Szepski 30

Diagram Przypadków Użycia

Page 31: UML

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